After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 559308 - Add ext4 detection
Add ext4 detection
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.18.x
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
: 571647 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-11-04 17:46 UTC by Laurent Bigonville
Modified: 2018-05-24 11:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Laurent Bigonville 2008-11-04 17:46:28 UTC
I've just bought a new external HD and I would like to give ext4 a try.

The partition is correctly mounted as ext4(dev) but the General tab of the Property dialog is still showing ext3. The fs type is correctly reported under the "Volume" tab
Comment 1 gbil 2009-02-22 20:44:35 UTC
Also seen here. 


Using nautilus-2.24.2 under Basic tab filesystem is reported as ext3 while in Volume tab is correctly reported as ext4. 


Comment 2 Cosimo Cecchi 2009-02-22 20:49:30 UTC
-> GIO

That string is provided directly to us from g_file_query_filesystem_info (), so this is a bug in GIO itself.
Comment 3 A. Walton 2009-02-22 20:53:53 UTC
*** Bug 571647 has been marked as a duplicate of this bug. ***
Comment 4 A. Walton 2009-02-22 20:55:25 UTC
From the other bug:
"using just the magic field as we do now, it is not possible to discriminate
e.g. ext2/ext3/ext4. Ways to improve this would be to use libblkid, or look at
how the file utility does it.

See https://bugzilla.redhat.com/show_bug.cgi?id=480218
Comment 5 Alexander Larsson 2009-02-24 12:37:51 UTC
I don't think its reasonable to link glib to weird filesystem libs just to get this right. Furthermore, my guess is that those libs try to read the block device to sniff things, which is not something you can always do due to permissions and whatnot.

Maybe we can just change the string to "ext3/ext4"? (I don't think ext2 is all that much used anymore.)
Comment 6 Matthias Clasen 2009-02-24 15:01:02 UTC
I agree that it is not reasonable to link glib to libblkid. I had idly wondered if it would make sense to have this functionality in the backend ? gvfs would certainly be more amenable to wierd linking....
Comment 7 Alexander Larsson 2009-03-03 14:43:35 UTC
This is part of the local filesystem implementation of GFile, so gvfs is not involved atm. Thats not saying it couldn't though, but I don't think its a good idea to start trying to read the filesystem data just to get this difference. I'd rather just display ext3/4.
Comment 8 Matthias Clasen 2009-04-03 04:26:01 UTC
How about reading /proc/self/mountinfo ? 

I have changed the string to "ext3/ext4" for now, anyway.
Comment 9 Alexander Larsson 2009-04-03 07:27:10 UTC
Parsing /proc/self/mountinfo might work on more recent linux versions.
Comment 10 Sven Herzberg 2009-10-23 12:56:06 UTC
(In reply to comment #8)
> How about reading /proc/self/mountinfo ? 
> 
> I have changed the string to "ext3/ext4" for now, anyway.

I that considered as a fix? Should we close this bug?
Comment 11 Christian Dywan 2009-10-30 21:29:10 UTC
I would like it if ext4 could be detected at least on systems where that is possible. There are a lot of differences in these filesystems, so imho it's worth differentiating them. /proc/self/mountinfo could be used when available, it is easy to parse, otherwise "ext3/4".
Comment 12 Alexander Larsson 2009-11-02 09:46:21 UTC
Reading /proc/self/mountinfo itself is certainly easy, however mapping from a pathname (as given to g_file_query_filesystem_info and statfs) to the mount that the path is on is a bit harder. Its certainly doable though.

I think just matching the line with the major/minor taken from the stat will be good enough for the filesystem type, as in this case we don't need to care about things like namespaces, multiple mounts, shadowed mounts or bind mounts. Needs some testing though.
Comment 13 GNOME Infrastructure Team 2018-05-24 11:37:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/172.