bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list


From: Bob Proulx
Subject: bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
Date: Wed, 30 Jan 2013 15:44:18 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

Bernhard Voelker wrote:
> Reading (again) through it, it seems to me that we have 2 arguments:
> 
> a) basically, it would be good to be able to distinguish ext2/ext3
> from ext4 while it is problematic in the real world due to EXT4's
> nature - or at least would bring a lot of code into stat.

Yes.  And all of the problems of trying to chase details of every
random filesystem.  It just seems like a bad slippery slope.

> b) just adding "ext4" to "ext2/ext3" as it has already been proposed
> by several people could break existing scripts that use code like this:
> 
> >       test "$(stat -f -c %T .)" = ext2/ext3 && ...
> 
> I'm wondering how often users check for the hard coded string
> "ext2/ext3"? Do we have any numbers?

I haven't had any reason to check for that particular value.  And
therefore for me the question is rather abstract.  It would be very
useful to know the real world reason why people are looking at that
value in order to know what is best to do about it.

On the surface I don't think the proposed change is particularly
scary.  Not as compared to changing head/tail option syntax for
example.  Not as compared to changing regular expression range
interpretation and sort order in different locales for example.  But
both of those have changed in recent history.  This seems quite a bit
more mellow by comparison.

As someone with a lot of years and lines of script writing behind me I
would always be very paranoid about operations such as "destroy_data"
based upon some string value like this.  I like to think that I
wouldn't be fooled into a data loss because of something like this.  I
think changing it would have less impact than adding characters to the
'ls -l' mode display output for example.

However because the identifier is an ext2 identifier I would have
always reported it as ext2 regardless of whether ext3 or ext4 used it.
If there is no way to tell them apart then there is no way to tell.
Perhaps better to have reported the raw hex data value of it.

But that is all water under bridge now since the program was imported
with that "ext2/ext3" already emitted.  There is no difference in
identifier between those and the newer ext4.  I am inclined to say
that the identifier is "ext2" now even if ext5 uses it.  What if some
new xjzfs uses that same identifier?  It is the identifier that is
being reported and not the actual file system contents.  Therefore I
wouldn't change it unless the identifier itself is changed.

Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]