bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
reopen 13582 severity 13582 wishlist thanks Bernhard Voelker wrote: > I feel very sorry if my words were a bit harsh. > > Admitted, you refer to this in README: > > If your patch adds a new feature, please try to get some sort of consensus > that it is a worthwhile change. One way to do that is to send mail to > bug-coreutils@gnu.org including as much description and justification > as you can. Based on the feedback that generates, you may be able to > convince us that it's worth adding. I think that text should be updated to reflect the current positioning of the bug tracker behind the bug-coreutils address. Let's do that in a separate discussion not in this one about stat and ext*. > Hmm, in my opinion and what I have experienced in the last 2+ year > on the coreutils and bug-coreutils mailing lists, real bugs (or if > the user thinks it is one) should be handled in bug-coreutils, while > general discussion issues and topics including patches which need some > consensus (or review) should go to the main coreutils mailing list. > > But as Bob also stated off-list, your patch is some corner case: > > But it is a grey area needing a judgement call. Certainly a > submission that is simply, "what do you think about this" would > be a discussion issue. > > Sorry again. And I had also said this there too: I think it is okay to have actual patch submissions open tickets for tracking. Those are pretty rare in general. When they implement features they can be marked as a wishlist item. If that feature is decided not to be done then they can be marked as "wontfix". For this particular item I think that may be more appropriate as the topic has come up more than once. And so I have done that. I didn't tag it wontfix because I am not sure the discussion is complete to concensus yet. Perhaps some different but better behavior will result. Bob
bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
I am just adding references here to tie in the previous discussions.
The bugzilla.redhat.com discussion actually has the best analysis of
the problem. However let me summarize (and plagarize) as best as I
can here.
In https://bugzilla.redhat.com/show_bug.cgi?id=485507
Eric Sandeen proposed to add ext4 to the list of names
currently reported for that type of file system ("ext2/ext3").
In response Jim stated:
http://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00160.html
I'm reluctant to change that string, because doing so might
well break scripts that rely on them:
case $(stat -f --format %T .) in
ext2/ext3) ;;
*) destroy_partition ;;
esac
Sure, script writers might well anticipate this and
prefer to use the %t directive to get the type in hexadecimal,
but that's far less readable.
How much code (and how ugly) would be required to distinguish ext4
from ext[23]?
This was further reinforced by Jim in a later discussion:
http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00229.html
For the ext4-adding part, I'm a little reluctant,
because it may break scripts that test via e.g.,
test "$(stat -f -c %T .)" = ext2/ext3 && ...
rather than the more portable -- in potential retrospect:
case $(stat -f -c %T .) in
ext2/ext3*) ... ;
esac
In the previous thread Eric suggested some pseudo-code flow to
distinguish ext4 from ext* but it would have needed significant effort
to complete. This was followed up in the in the bugzilla trail
especially this where we see that the problem of distinguishing ext4
is not trivial and opens a box of problems. I think it is worthwhile
to share it here.
https://bugzilla.redhat.com/show_bug.cgi?id=485507#c7
Eric Sandeen 2012-04-25 17:05:14 EDT
A big part of the problem is that "ext4" is a big, random collection
of features. It's more a new driver codebase containing various &
sundry new things, than a fixed on-disk format.
You can turn any/all of the following on or off and mount it with the
ext4 driver:
* extents
* delalloc
* flex_bg
* journaling
* 64-bitness
* "bigalloc"
* etc
So the question becomes, what exactly _is_ ext4? Best we can do is
"ext2/3/4" or so, I think.
https://bugzilla.redhat.com/show_bug.cgi?id=485507#c8
Ondrej Vasik 2012-04-25 19:33:20 EDT
But upstream (Jim Meyering) already rejected ext2/3/4 change - as it
may break scripts - and recognizing ext4 based on some feature might
be a tricky thing - as Eric mentioned - and will polute the stat
code. Bad luck that ext2/3/4 uses the same magic for all filesystems.
https://bugzilla.redhat.com/show_bug.cgi?id=485507#c9
Eric Sandeen 2012-04-25 20:08:06 EDT
Best to close it WONTFIX then, I guess?
https://bugzilla.redhat.com/show_bug.cgi?id=485507#c10
Ondrej Vasik 2012-04-26 02:06:03 EDT
Probably... closing WONTFIX, anyone - feel free to reopen it if you
find an easy way how to reliably distinguish ext2/3 and ext4
filesystem (or just propose it as reply in upstream thread mentioned
in comment #4 or #5 - as this possible change has to be done/accepted
upstream). These ways I'm aware of are too big for stat.c code.
I think the above rationale is still a good place to start. It is
unfortunate that ext4 is using the same identifier as ext3. And the
same that ext3 used the same identifier as ext2.
Bob
bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
On 01/30/2013 10:27 PM, Bob Proulx wrote: > I am just adding references here to tie in the previous discussions. Thanks for that excellent summary. 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. 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? Have a nice day, Berny
bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
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
bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 1/30/13 1:25 AM, Paul Eggert wrote: Can you use GDB to debug the situation? No. That is, I'm willing but apparently not able. Try running something like this: gdb test-getcwd b getcwd r fin p errno GDB didn't seem to offer up much. It was able to find getcwd (after loading shared libraries) and set the breakpoint but it would exit out (still with error code 7) before reaching the break. After looking through test-getcwd.c, though, I don't know how that's possible. I can say for sure that when GDB was setting the breakpoint, it was finding libc's getcwd, not GNUlib's (based on its address). That sort of thing. Hopefully, this qualifies: Because I was unable to get anything else out of GDB (that was literally my first time ever using the program), I resorted to directly editing test-getcwd.c a few times and determined that errno gets set to ENOENT before triggering the failure. Global Odey
bug#13516: tests/rm/unread3 fails on Mac OS X 10.8
On 01/30/2013 03:59 PM, Global Odey wrote: > On 1/30/13 1:25 AM, Paul Eggert wrote: >> Can you use GDB to debug the situation? > No. That is, I'm willing but apparently not able. >> Try running something like this: >> >> gdb test-getcwd >> b getcwd >> r >> fin >> p errno > GDB didn't seem to offer up much. It was able to find getcwd (after loading > shared libraries) > and set the breakpoint but it would exit out (still with error code 7) before > reaching the break. What happens if you put a breakpoint on rpl_getcwd instead? Use "b rpl_getcwd". That should get Gnulib's getcwd instead of libc's.
