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 651559 - Doesn't compile against parted 3.0
Doesn't compile against parted 3.0
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
GIT HEAD
Other Linux
: Normal normal
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
: 651654 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-31 15:51 UTC by Ian Abbott
Modified: 2011-07-18 19:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ian Abbott 2011-05-31 15:51:02 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
Comment 1 Curtis Gedak 2011-05-31 16:22:58 UTC
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.
Comment 2 Sven 2011-06-01 11:55:14 UTC
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
Comment 3 Curtis Gedak 2011-06-01 14:54:18 UTC
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.
Comment 4 Steven Shiau 2011-06-01 15:02:38 UTC
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.
Comment 5 Curtis Gedak 2011-06-01 15:19:59 UTC
(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.
Comment 6 Ian Abbott 2011-06-01 15:51:11 UTC
(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.
Comment 7 Curtis Gedak 2011-06-01 19:04:00 UTC
*** Bug 651654 has been marked as a duplicate of this bug. ***
Comment 8 Steven Shiau 2011-06-02 00:30:33 UTC
"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.
Comment 9 Curtis Gedak 2011-06-08 19:40:51 UTC
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?
Comment 10 Curtis Gedak 2011-06-09 16:08:56 UTC
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.
Comment 11 Keshav 2011-06-09 18:21:59 UTC
What about fatresize http://sourceforge.net/projects/fatresize/ for resizing FAT filesystems?
Comment 12 Curtis Gedak 2011-06-09 23:08:42 UTC
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.
Comment 13 Ian Abbott 2011-06-10 09:30:47 UTC
(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.)
Comment 14 Steven Shiau 2011-06-10 09:37:43 UTC
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.
Comment 15 Curtis Gedak 2011-06-10 14:41:15 UTC
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.
Comment 16 Ian Abbott 2011-06-10 17:12:19 UTC
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.
Comment 17 Curtis Gedak 2011-06-11 15:26:31 UTC
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.
Comment 18 Curtis Gedak 2011-07-18 19:19:43 UTC
The fix for this bug was included in the GParted 0.9.0 release on July 18, 2011.