GNOME Bugzilla – Bug 723571
Copying ext4 partitions should not fix the source but the destination
Last modified: 2020-11-13 10:41:11 UTC
When copying an ext4 partitions with errors, gparted first tries to fix this source partition by running e2fsck and then to copy the partition it has "fixed". In case the errors are caused by disk writing failures, this is likely to causes more damages and more data losses. Expected result: * Gparted should not modify the source partition; * Gparted should copy the raw data from the source partition; * Gparted should ask if the user wants to correct the errors on the _copy_! * Gparted should not correct the errors automatically (it was maybe the last time the drive could be read, it is then safer to attempt to correct from a third copy)
Thank you Adrien for your interest in GParted. Prior to move/copy/resize operations, GParted is designed to always perform a file system check. If the file system check fails, then GParted aborts the operation. The logic for this is if the file system cannot be fixed, then GParted should not proceed with the operation because the move/copy/resize will not result in a consistent file system upon completion. This is important because some file systems require meta data changes when the partition start is changed. A good example of this is with NTFS which internally stores the number of "hidden" sectors before the start of the file system -- this value must be updated. Hence if an NTFS file system is in an inconsistent state, then GParted will not proceed with move/copy/resize. Some file systems also provide their own copy tools, such as e2image for ext2/3/4, and ntfsclone for ntfs. These tools require a consistent file system to work properly. For file systems that do not include such copy tools, GParted uses it's own internal copy algorithm. In addition, since GParted operations do require writing to disks to update partition boundaries and contents, it is more advisable to use a tool like dd or ddrescue to make an image copy of the entire disk device prior to attempting data recovery. Does the above explanation adequately describe why GParted works the way it does?
Thanks for the explanation Curtis. I understand that some operations requires modifications of the partition (especially resizing). Yet, the name of the operation "copy" or "move" is misleading as it performs an additional - and possibly unwanted - operation. Moreover this additional operation may lead to data losses (for example if the filesystem is broken because of a failing drive). I would suggest that at least the names of the operations match what is performed, i.e. "Fix and move", "Fix and copy", and "Fix and resize" (or "Check, fix and move", "Check, fix and copy", and "Check, fix and resize"). Or if the check shows that fixes are needed, Gparted should ask confirmation before proceeding with modifications.
Thank you for responding. Your concern about fixing a partition file system on a failing disk is valid. Having said that, GParted tries to enable users to perform a variety of partition operations without the users needing to know all the technical details regarding MBRs, EBRs, FS Metadata, etc. As such I believe the current default behaviour is well suited to the majority of use cases. However, I also recognize the need for transparency in what operations do. Personally I'm not a fan of complicating the menu entries with long titles, and in the case of resize/move operations the actual steps depend on what the user changes in the resize/move dialog. Perhaps adding a default enabled "fix file system" checkbox to the copy/move/resize dialog might be an option. There are probably other ways to help improve the transparency of operations if anyone has additional ideas.
I have to agree that this check should be removed. If the copy tool fails because the source is inconsistent ( and it really shouldn't ), then the user can check it manually. Besides the check causing harm to a failing drive, it also is most often simply a waste of time.
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).