GNOME Bugzilla – Bug 792936
Limits for maximal size of partition / filesystem in GUI dialogs does not work
Last modified: 2020-11-15 12:32:38 UTC
GUI dialogs allow to choose size of filesystem larger then supported. This is bug in GUI dialogs which do not respect constrains declarated by filesystem classes. Steps to reproduce for UDF filesystem: https://bugzilla.gnome.org/show_bug.cgi?id=787204#c26 https://bugzilla.gnome.org/show_bug.cgi?id=787204#c23 Steps to reproduce for any filesystem on MBR/msdos partition layout: 1. Take block device larger then 2TB, it can be virtual loopback. 2. Create a clean new MBR/msdos partition layout on it 3. Try to create a new partition (with any filesystem) with maximal size 4. Apply for changes Now GParted throw error message Steps to reproduce for FAT16 filesystem: 1. Again use 2TB+ disk, but partition layout is irrelevant (problem happen for both GPT and MBR) 2. Create a new 200MB FAT16 filesystem 3. Apply for changes 4. Resize filesystem from 200MB to 3TB 5. Apply for changes Now GParted throw error message Steps to reproduce for FAT32 filesystem: 1. Again use 2TB+ disk 2. Create a new empty GPT layout on it 3. Try to create a new partition with FAT32 filesystem on it with maximal size 4. Apply for changes GParted does not throw any error. Filesystem is created. But in detailed mkfs.fat log is line: "Warning: target too large, space at end will be left unused" It means that user tried to create too large filesystem, but only first 2TB was formatted and remaitning space is unused and cannot be used. Problem is with usage of floating point rounding, ceil() and floor() functions. Function ceil() returns number higher then specified which violates constrain for maximal limit. Moreover floating point is in some cases really strange (for those who do not know how is working) and for large values it can loose precision resulting in sizes different as specified or expected.
Just for reference, I think we have previously found the same issue with 32bit ext2/3/4 file systems being limited to 16 TiB - 4 KiB. At that time we also discussed the issue but papered over it by rounding down the maximum file system sizes to be a whole multiple of mebibytes. Commit: Limit maximum ext2/3/4 volume size to just less than 16 TiB (#766910) https://git.gnome.org/browse/gparted/commit/?id=af17808d08c762b1c3b6093211a91290df2c993e Code commend: FIXME: Rounding down to whole MiB here should not be necessary. The Copy, New and Resize/Move dialogs should limit FS correctly without this. See bug #766910 comment #12 onwards for further discussion. https://bugzilla.gnome.org/show_bug.cgi?id=766910#c12
Are you going to fix these problems?
One day maybe. At the moment this is not a priority.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).
Migrated to https://gitlab.gnome.org/GNOME/gparted/-/issues/121