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

[Bernhard Voelker]

On 01/30/2013 11:44 PM, Bob Proulx wrote:
> Bernhard Voelker wrote:
>> 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?

> On the surface I don't think the proposed change is particularly
> scary.
> [...]
>
> 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.
> [...]

That is about the same what I was thinking.
When someone has written a script managing partitions and file systems,
then I think he would (hopefully) never just use that well-cited
snippet to guard existing data against destroying:

      case $(stat -f --format %T .) in
        ext2/ext3) ;;
        *) destroy_partition ;;
      esac

First, it's running on Linux or another *NIX flavor, i.e. such
a script would have to check for many other file system types, too.
Is that reliable? Probably not.

Second, I think such a script would probably rely on other things
rather than using coreutils' stat - e.g. letting the kernel decide
by trying to "mount -r". Even 'file' knows how to distinguish
between ext3 and ext4:

  $ file -s /dev/sdb3
  /dev/sdb3: Linux rev 1.0 ext3 filesystem data, UUID=<...>, \
  volume name "home" (needs journal recovery) (large files)
  $ file -s /dev/sdb2
  /dev/sdb2: Linux rev 1.0 ext4 filesystem data, UUID=<...>, \
  volume name "rootfs" (extents) (large files) (huge files)

And third, if such a script really relied on stat, then I think
it would rather use `stat -f --format %t`, i.e. the type in hex,
wouldn't it?


> 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.

Right, stat is just reporting the human readable form of the
magic number. If that number is used by different file system
types, then stat should report all possibilities. It's the problem
of those file systems to use different magic numbers (or not).
I mean, the ext4 development team has deliberately chosen not to
use a new number - they will have had their reasons.

With all that said, I'd +1 the patch.
WDYT?

Have a nice day,
Berny