GNOME Bugzilla – Bug 651559
Doesn't compile against parted 3.0
Last modified: 2011-07-18 19:19:43 UTC
parted (and libparted) 3.0 removed a lot of functions from the API for manipulating filesystems. Because of this, gparted is incompatible with parted 3.0 at the compile and link levels (though it doesn't get as far as linking). It's hard to see how this could be fixed except by producing a crippled version of gparted when a cripped version of parted is detected. Here is the the relevant part of the NEWS entry for parted 3.0: ** Changes in behavior Remove all FS-related (file system-related) sub-commands; these commands are no longer recognized because they were all dependent on parted "knowing" too much about file system: mkpartfs, mkfs, cp, move, check, resize. This change removes not just the user interface bits, but also the library functions and nearly all of the underlying FS-munging code. The code embedded in Parted by which it knew about those file systems was so old, unmaintainable and buggy that while seemingly drastic, this change is like removing a gangrenous toe. Here is the list of removed functions: ped_file_system_clobber ped_file_system_open ped_file_system_create ped_file_system_close ped_file_system_check ped_file_system_copy ped_file_system_resize ped_file_system_get_create_constraint ped_file_system_get_resize_constraint ped_file_system_get_copy_constraint This change also removes the corresponding function members from "struct _PedFileSystemOps": clobber open create close check copy resize get_create_constraint get_resize_constraint get_copy_constraint
Thank you Ian for finding and reporting this problem. Unfortunately the solution you propose (a reduced functionality version of GParted) is probably the only solution to get GParted to work with parted-3.0.
It was long ago, that I read in the man page, help, or whatever, that future versions of parted would be less about manipulating filesystems but only about manipulating partition tables. I think, this is a long planned move by the parted authors. Maybe you can move code from parted 2.x to gparted to make it work with parted 3.x
My thoughts are that a better place for the FAT16/FAT32 resizing code is in a command line utility, perhaps as part of dosfstools. This would then mimic resize2fs and the e2fsprogs package In this way all of the file system specific code would be in a package specific to the file system.
Second to you, Curtis. BTW, besides the FAT16/32 file systems, does any other file system resizing in GParted still rely on parted? Or FAT is the only one? How about cloning? If it relies on parted, maybe it's time to use partclone? Steven.
(In reply to comment #4) > BTW, besides the FAT16/32 file systems, does any other file system resizing in > GParted still rely on parted? Or FAT is the only one? Parted versions prior to 3.0 also support shrinking HFS/HFS+ file systems. Hence this functionality is also lost with parted 3.0. > How about cloning? If it relies on parted, maybe it's time to use partclone? In terms of copying partitions, GParted performs a sector by sector copy for all partitions with the exception of file systems such as NTFS and XFS. For NTFS GParted uses the ntfsclone command line utility. For XFS GParted uses the xfsdump and xfsrestore command line utilities. In terms of moving partitions, GParted uses the same sector by sector copy code. This code determines whether to start copying from back to front or front to back depending on which direction the partition is being moved. Hence for the most part partition "cloning" does not rely on parted's file system knowledge. If partclone uses intelligence in determining which sectors to copy, then it might provide a speed improvement when copying partitions as compared to GParted's sector by sector copy code. I think it would be best to consider the use of partclone as a separate enhancement request from this report which deals with the loss of functionality in parted/libparted.
(In reply to comment #5) > If partclone uses intelligence in determining which sectors to copy, then it > might provide a speed improvement when copying partitions as compared to > GParted's sector by sector copy code. I think it would be best to consider the > use of partclone as a separate enhancement request from this report which deals > with the loss of functionality in parted/libparted. Just FYI, partclone does determine which sectors to copy, but it doesn't support the use of offsets into the source or destination and doesn't support overlapping source and destination.
*** Bug 651654 has been marked as a duplicate of this bug. ***
"I think it would be best to consider the use of partclone as a separate enhancement request from this report which deals with the loss of functionality in parted/libparted." -> Agreed. Steven.
Status Update: I am actively working on a solution to enable GParted to compile against parted-3.0. As alluded to earlier, this will result in the inability to resize FAT16, FAT32, HFS, and HFS+ file systems. At least until some other keen project decides to build this functionality. If anyone knows of such a project, then please let me know so that we can consider using the project tools to replace this missing functionality. While working on a solution, I discovered that GParted used the libparted library to determine the number of used sectors in HFS and HFS+ file systems. At the moment I do not know a way to determine the number of used or unused sectors without mounting the partition. For FAT16 and FAT32 file systems, this information is gleaned from the output of "dosfsck -n -v /path-to-partition". Does anyone know of a way to acquire the number of either used or unused sectors in an HFS or HFS+ file system without mounting the partition?
Three individual changes have been committed to the git repository to enable GParted to compile and link with libparted 3.0. When GParted is compiled and linked with libparted 3.0 the following functionality is lost. - Loss of ability to grow and shrink FAT16 and FAT32 file systems - Loss of ability to shrink HFS and HFS+ file systems - Loss of ability to determine used and unused sectors in HFS and HFS+ file systems - Loss of ability to erase file system signatures on partition create and format It is hoped that other free software projects will include some or all of the above lost functionality, which can then be added back to GParted. The last commit also includes a change in how FAT16 and FAT32 file systems are moved. Specifically the move is now performed internally by GParted when linked with libparted 3.0. The move functionality is provided by libparted for prior libparted versions (e.g. less than 3.0). The relevant three commits can be viewed at the following links: Minor format changes to final configuration summary http://git.gnome.org/browse/gparted/commit/?id=9cdd6c00920f3ff90e99d0805ce4512982cfea06 Add configure check for libparted version 3.0.0 or higher http://git.gnome.org/browse/gparted/commit/?id=13568bcee7dad4e63346c4570d0238c68831730d Enable compile and link with libparted 3.0 (#651559) http://git.gnome.org/browse/gparted/commit/?id=8a58b5b53e67bb7c9ac1b8d4fbef0e2b50139acf These commits are planned for inclusion in the next release of GParted.
What about fatresize http://sourceforge.net/projects/fatresize/ for resizing FAT filesystems?
Thank you Keshav for the suggestion of fatresize. Unfortunately fatresize also uses the libparted library functions for resizing FAT16 and FAT32 file systems. Hence fatresize will also lose the ability to resize file systems _if_ it would compile and link with (lib)parted 3.0. If you do learn of any other free software tools that permit FAT16, FAT32, HFS, or HFS+ file system resizing, then I would appreciate a link to these.
(In reply to comment #10) > - Loss of ability to determine used and unused sectors in HFS and > HFS+ file systems partclone has some code for determining the used and unused sectors in HFS+ file systems without using any special libraries and the code is quite small. The code is in partclone's src/hfsplusclone.c file. (Note the code's definition and use of the functions reverseShort() and reverseInt() assumes the host is little-endian, and these should be replaced with portable "big-endian to host order" or "network to host order" functions.)
I have discussed with Thomas Tsai (Partclone's main developer), and he said it's not a problem to have an option to let partclone to output the used and unused blocks info. If this helps, he can implement that. Steven.
Thanks Ian for the partclone suggestion, and Steven for discussing this with Partclone's main developer. GParted uses the number of used and unused sectors for two purposes: 1) To show the user how much free space is left in the partition 2) To limit in the GUI how small the file system can be shrunk Point number 2 is probably the most important to users of HFS+ file systems when they are running GParted. If users only wish to see the free/used space then they can use the df command while the file system is mounted. With this in mind, it would be nice if partclone could quickly output this information in a form that GParted could parse. However, I think users will be mostly missing the ability to shrink HFS+ file systems. There have been some mention of a project to resize HFS/HFS+ file systems on the parted mailing list (see bottom two paragraphs of message): http://lists.alioth.debian.org/pipermail/parted-devel/2011-June/003886.html If this HFS/HFS+ resizing project comes to fruition, then the information on free/used sectors would certainly be helpful. This information might even be provided by the project too. So in summary it would be useful to GParted to have the free/used sectors of HFS+ file systems, but mostly if there is also the ability to resize the file system too.
Hi Curtis, partclone-0.2.24 has a -D (--domain) option which outputs a map of used and unused areas in a format suitable for use with GNU ddrescue's --domain-log option. The unit of granularity is bytes, not sectors or blocks. If only HFS+ is a problem, it might be easier just to parse the filesystem structures directly to determine used/unused sectors. There are some problems with partclone at the moment though: 1) Some of the supported filesystems need special patched libraries (e.g. for XFS); 2) At least some of the filesystem parsing code assumes the host uses little-endian byte-order (e.g. the HFS+ code); 3) Maybe not a problem, but it's still fairly new and immature compared to (lib)parted. It could do with more error checking of system & library calls.
Thank you Ian for the extra information about partclone. The data about used and unused sectors for HFS+ file systems is most important when determining a minimum value for shrinking a file system. Without the ability to shrink HFS+ file systems, the data about used/unused sectors simply becomes a nice to have. If GParted does not have this information, then it will still be able to perform actions other than resizing.
The fix for this bug was included in the GParted 0.9.0 release on July 18, 2011.