1 (edited by cabralgo 2021-08-28 01:58:18)

Topic: [Solved] Error during partition move to the left

I'll appreciate your help for a problem occurred during a partition move with Gparted 0.3.0 in a 931 Gib HDD, connected through USB. The disk was part of a notebook with W10, and it had 4 partitions. After deleting the small partitions #1, #3 and #4, I was moving to the left and also extending, the large partition #2 (about 920 Gib) in order to fit the whole disk, but the process suddenly stopped due an I/O error, when 29 Gib were already moved.
After the failure, and after several retries, the only option was exit the program.
Now, I can't access to my files: Windows reports that the disk has no format and Linux 18.04 only shows a small amount of files, probably these 29 Gib moved to the left.
I think that when I deleted partition #1, the freed space before partition #2 was 100 Mib, since it is a typical Windows boot partition #1.
I’ve tried to recover the files using Disk Drill, Wondershare Recoverit and the old Restorer Ultimate Pro, but most of the files doesn’t have a recognizable magic number ( extensions cae, jnl, stp, step… ) and the ones recognizable, are corrupted in some cases.
Do you think is there a way to perform a rollback, to get these 29 Gib moved again to its initial position ? Can I figure out which sectors where moved to the left ?
Thanks in advance.


Re: [Solved] Error during partition move to the left

I/O error means usually hardware error (failure of the drive itself or a bad cable/connector, a controller or USB interface problem, a power problem etc).
On a mswindows 10 system there is usually the EFI partition and a microsoft reserved partition. These partitions are rather small most of the times (100 MiB to 250 MiB), so there is no significant gain in disk space. Furthermore, they are needed for the O.S. boot and function, unless you use the drive just as a data drive (not as boot drive). For me, the "risk" of the growing operation (that involves a move to left) is rather too big. We have to take into account that the operation through the USB interface is slower or even very slower than with a SATA attached device, and this makes the risk bigger. That's why we always insist on the necessity of a backup before any operation on the partitions.
The "system restore" partition (often last in the hd space) is usually bigger (several GiB), so one can gain a significant disk space amount.

After the failure and stop the filesystem (ntfs) remains in a broken/corrupted state and the OS can't use it. Unfortunately after exiting/rebooting the GParted report information is gone (it stays in memory and can be accessed in html format from GParted).
In those move/expand to left operations GParted starts copying the partition blocks by groups. The group size is determined after a few tries in order to obtain the fastest transfer rate for the specific system. Without details of the operations we can't know exactly how many sectors to the left the content is moved, nevertheless you can try to look for matching sector content around the position of 29 GiB with a distance of about 100 MiB. I remember at least such a case reported here, that finished successfully.

Nevertheless I can't know if the MFT (the ntfs file table section) is corrupted. In that case recovery is even harder. There are chances to recover files with "photorec" software (free), nevertheless the filesystem tree structure is lost, and one can end with lots of good or corrupted files to be individually tested and sorted.

It is recommended to clone the hard drive before any recovery work, so that you can be able to repeat the attempts in case of failure.

*** It is highly recommended to backup any important files before doing resize/move operations. ***


Re: [Solved] Error during partition move to the left

Thanks for your reply. I've used Gparted so many times that I underestimated the risk and I'm paying for it. To be simple I talked about "my files", but they are not mine and I feel terribly guilty for my mistake.

I've tried to look in the nearby of 29 Gib to find matching sectors, with a distance from 0 to 200 Mib, but I couldn't find anything. Maybe I'm not selecting the right sectors

Can you explain how the process to move sectors works ? Does Gparted move all sectors (even those that are marked as available) or just those used file filesystem ?

I know tht the disk looked like

                    <-------- 920 Gib ------->
Sector   0  2048   

And after the incident is looking something like this

               <-------- 920 Gib ???-------->
Sector   0  2048   
         |    |ABC   CDEFGHIJKLMNOPQRSTUVWXY|   (please note that sector "C" is duplicated)

Do you think if I could find the moved sectors and return it to the original places I could maximize my odds to restore the whole partition ?



Re: [Solved] Error during partition move to the left

cabralgo wrote:

Does Gparted move all sectors (even those that are marked as available) or just those used file filesystem ?

It depends on the file system, for ext2/3/4 GParted uses the e2image utility to copy only the used data.  For NTFS, gparted will copy each and every sector from the source to the new destination.  The code that performs the copy is contained in CopyBlock.cc.

cabralgo wrote:

Do you think if I could find the moved sectors and return it to the original places I could maximize my odds to restore the whole partition ?

If you can restore the file system back to how it originally was then that certainly could help.  The challenge is to determine where in the copy process it failed.


Re: [Solved] Error during partition move to the left

Thanks again for your reply.

I'm really committed to solve the problem and your last message renewed my hope.

gedakc wrote:

If you can restore the file system back to how it originally was then that certainly could help.  The challenge is to determine where in the copy process it failed.

It's supposed that the copy process left 204800 sectors (100 Mib) of duplicated data before the failure.

I've tried unsuccesffully several approaches to identify the duplicated area. I've made manually some seeks using HxD (Hex Editor), I've used dd and hexdump to take samples (16 bytes every 1Mib) and I've imported it to an SQL Server trying to locate the beginning of this area, but nothing helped.

Is there any tool or an approach that you would recommend me to be successful?

Thank you.


Re: [Solved] Error during partition move to the left

I’ve solved the problem, and I'd like to share with you, the process that I did. It will be extense, but I hope it could help someone who needs it. I was always doing my work on a forensic image called “image.dd”, made with the program Testdisk.

The facts:

After the interruption of the moving process, the disk was arranged in this way.

               <------ 920 Gib ?? ------->
Sector   0  2048                     1900 mill

(please, note that "C" is duplicated)

The solution:

Fortunately, there was in the HDD some files with recognizable data inside, like XML or text files of which I know both, the content and the filename.

The first thing I did, was locate the $MFT table, at the beginning of the raw disk. It was in sector 2064, very close to sector 2048, a very common place to start the main partition. After that, I located the entry for a known filename. I read the data attribute and after some hex-to-dec and cluster-to-sector calculations, I found the theoretical position of this file. Let’s suppose that the position stored in the $MFT was “T” in the map described above.

I used HxD to see the content of this “T” and I found nothing there, but I performed a search starting from this sector, searching the known data inside the file. After some seconds, HxD located beginning the file about 1.7 million sectors beyond “T”. Let’s say that this real position was “U” in the same map.

With the information of the theoretical location in the entry of the $MFT (“T”), and the actual position of the file (“U”), I calculated the size of the movement to the left, that Gparted was performing before the USB failure. It was 1.716.224 sectors, equivalent exactly to 838 Mib. It was good to see an integer number of Mebibytes.

I was unsure about the amount of data that had been moved to the left, but, using a little loop in a linux shell, I got the first 16 bytes from every 1 Mib block, starting in an offset of 10 Gib and finishing in 50 Gib. The code that I used was something like

for k in (671088640.. 3355443200..65536)
    dd if=image.dd bs=16 skip=k count=1 | hexdump -C

The output was a text file, that I decided analyze in Excel, but I could have made it in MySQL. I compared the samples with the data contained in a particular cell with the data 838 cells ahead. Quickly, I realized the first duplicated sector was 41.231.296, and obviously, there was 838 cells duplicated data in Excel. The corresponding sectors to these cells were in the zone of “C” in the map above, duplicated indeed.

Using again HxD, I deleted 1.716.224 sectors starting at sector 41.231.296. To be clear I deleted one of the two sector “C”. I saved the changes and the program took about 3 hours, because it had to write about 930 Gib of data.

The structure now, had no duplicated sectors.

               <------- 920 Gib  ------->
Sector   0  2048                     1900 mill

Finally, I mounted the image in Windows using OSFMount, in writable cache mode and after some verifications made automatically by Windows 10, the partition was there, 100% readable.

I promised me, “always, but always, perform a backup before any risky action”.


Re: [Solved] Error during partition move to the left

That's great you were able to recover your data.  Thanks also for posting the steps you used to recover your data, and for editing the post title to add "solved".  This can help others searching for answers to similar situations.