GNOME Bugzilla – Bug 746559
Various operations fail when following paste into existing partition
Last modified: 2015-08-03 17:30:00 UTC
Created attachment 300016 [details] Broken operational details On a quick test this has been broken for ever. Confirmed with various back to GPared 0.2.5! Full operational details are attached. Summary of operational details: + Copy /dev/sdb5 to /dev/sdb7 ... + copy file system of /dev/sdb5 to /dev/sdb7 + Format copy of /dev/sdb5 as fat32 + calibrate copy of /dev/sdb5 path: /dev/sdb7 ... ... + create new fat32 file system mkdosfs -F32 -v -I -n " " copy of /dev/sdb5 copy: No such file or directory What is happening is that the paste operation is changing the partition name to "copy of /dev/SRCPTN" for display purposes and the format operation is working with this name and giving it to the mkfs command instead of a real partition name. Since the bug has existed forever, and no one else has reported this I assume no body has actually tried to do this. No need to try to rush a fix for the impending GParted 0.22.0 release scheduled for Monday 23-Mar-2015. Mike
Results from other combinations ... * Paste into existing + Label * Paste into existing + new UUID both fail in in the same way, and are reasonable sequences users might perform. * Paste into existing + check succeeds!
Changed summary from: Paste into then format the same partition sequence fails to: Various operations fail when following paste into existing partition
Created attachment 300149 [details] [review] Calibrate the right partition objects (v1) Hi Curtis, Here's patchset v1 to fix this. Thanks, Mike
Created attachment 300373 [details] [review] Calibrate the right partition objects (v2) Hi Mike, Thanks for identifying and fixing this issue. My review and testing of patch set v1 in comment #2 has gone well. There are two minor changes I would suggest: 1) Minor spelling mistake "know" should be "known" in the code comment for P2. ... boundary is know before ... ... boundary is known before ... 2) Small change to the help manual wording, now that the UUID and file system label changed can be successfully queued immediately after a copy/paste operation is queued (for example before applying the copy/paste operation. This is P3. From: After you have applied the copy operation: To: After you have queued or applied the copy operation: If you are in agreement with the changes, then please feel free to commit the entire patch set. Curtis
Hi Curtis, Your patchset v2 is good. Nice tweek to the GParted Manual. I even tested doing the following sequence: copy into existing, label, new UUID, format src and: copy into existing, label, new UUID, delete src Both work. But I don't think we should make the same document change to the next bullet point point making it: * After you have queued or applied the copy operation, delete or reformat the source partition. Users are better off reformatting or deleting the source separately though. The following changes have been applied to the GIT repository for inclusion for the next release of GParted. Fix failing operations following paste into existing partition (#746559) https://git.gnome.org/browse/gparted/commit/?id=d9993c21ba2f78cd1a1e64d7d5fafb17e73f9f81 Refactor operation cases in apply_operation_to_disk() (#746559) https://git.gnome.org/browse/gparted/commit/?id=cca8a55f51da012b412064f2db9f4e60056afc5e Minor change to help manual caution when copying a partition (#746559) https://git.gnome.org/browse/gparted/commit/?id=dcab9ad845be563cf7bf15785f428e3885c84b4e Thanks, Mike
This enhancement was included in the GParted 0.23.0 release on August 3, 2015.