Hi Simon, [email protected] wrote: > Am Saturday 13 October 2012 18:33:35 schrieb Jean-Pierre André: > >> Hi Simon, >> >> [email protected] wrote: >> > Hi People, >> > >> > I created an image with ntfsclone and am now unable to restore it. >> > >> > This is what ntfsclone reports when i try to restore the image: >> > >> > ntfsclone v2011.4.12 (libntfs-3g) >> > Ntfsclone image version: 10.1 >> > Cluster size : 4096 bytes >> > Image volume size : 628592312320 bytes (628593 MB) >> > Image device size : 628592315904 bytes >> > Space in use : 285916 MB (45.5%) >> > Offset to image data : 56 (0x38) bytes >> > >> > Variant 1: >> > ntfsclone -r backup.ntfs -O /dev/sda1 >> > >> > ntfsclone aborts with the following error message: >> > ERROR(22): restore_image: lseek: Invalid argument >> > >> > I strace'ed ntfsclone and found that it tries to lseek to >> >> 0x1000000000 which >> >> > results in the error "invalid argument" (if you need i can upload the >> > complete strace log) >> >> The "restore_image: lseek:" errors are seeks into the >> target partition. The first thing which comes to mind >> is that the target partition is not big enough. >> >> You need a 629GB partition, and this is a seek at 69GB, >> the only other reason I can imagine for the seek to fail >> is running on an old hardware, not able to deal with >> offsets greater than 0x1000000000. >> >> > Variant 2: >> > ntfsclone -r backup.ntfs -O -> /dev/sda1 >> > >> > no error are reported, but the filesystem cannot be mounted >> >> afterwards. >> >> > it complains about Record 0 having an invalid magic. >> > >> > As far as i understood from google'ing the web, is that this version of >> > ntfsclone has a bug and the image is invalid. Now i wonder if it is >> >> in some >> >> I have no trace of a similar problem. >> >> > way possible to at least extract the files from the image? (i don't >> >> need any >> >> > metadata, or boot sector, or other stuff from windows) >> >> But the metadata, boot sector, etc. are required to rebuild >> the files, as the ntfsclone images keep the original >> scattering of files. >> >> > PS: >> > I also tried to restore with newer versions of ntfsclone, with mostly >> >> the same >> >> > result. The newest version (compiled from source) aborts with the >> > message "image corrupted" after about 0.12% progress. >> > >> > I used that old version because it gets shipped with the SuSE install >> >> disks. >> >> The changes since 2011.4.12 are minimal, so I would expect >> getting the same behavior. >> >> Note : I will not be able to dig into this issue next week, >> please be patient, and post new findings you may have in the >> meantime. >> >> Regards >> >> Jean-Pierre >> > Hi, > > Thanks for your quick reply. > There's no rush with this problem. I need the data at some point but not > immediately. > > > First off, i was wrong about the lseek-offset. > The correct offset it tries to seek to is "4503599627370496" (decimal) or > 0x10000000000000 (i was missing a few "0"'s) > The partition is of course not of *THAT* size. I tried serveral partition > sizes (the harddisk itself is bigger). I tried both sizes ntfsclone reported > (628592312320 bytes and 628592315904 bytes) as well as 700 GiB and a few > other. > The "Variant 1" always fails with the lseek-problem. > Variant 1 strace log file: http://www.sbsw.net/ntfsclone.strace.gz
The image is corrupted. See from line 219238 in the strace file : read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(3, "\0", 1) = 1 read(3, "\0\0\0\0\0\0\0\0", 8) = 8 lseek(4, 0, SEEK_CUR) = 297283584 read(3, "\0", 1) = 1 read(3, "\0\0\0\0\0\0\0\0", 8) = 8 lseek(4, 0, SEEK_CUR) = 297283584 From there on, there is a succession of reading one byte whose value is 0, which means skipping in the output partition the number of clusters shown in the next eight bytes. The subsequent reading of eight bytes yields zero clusters to skip, which is obviously wrong, and leads to repeat the seek to 297283584. At least ntfsclone should check the invalid input.... Now, based on the strace output, I can determine where the corruption is in the input file : at 297221153 0x11b73c21 : read(3, "\1", 1) = 1 at 297221154 0x11b73c22 : read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 at 297225250 0x11b74c22 : read(3, "\1", 1) = 1 at 297225251 0x11b74c23 : read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 at 297229347 0x11b75c23 : read(3, "\0", 1) = 1 at 297229348 0x11b75c24 : read(3, "\0\0\0\0\0\0\0\0", 8) = 8 Reading at 0x11b74c22 yields a byte with value 1 and a reasonable cluster filled with 4096 zeroes. At 0x11b75c23 there is a byte with value 0 followed by a count of zero clusters to skip. This is wrong. There are apparently a lot of zeroes after that. However at 0x11b76c24 I see another byte with value 1, and similarly at 0x11b77c25 and 0x11b78c26 So, from 0x11b76c24 there are valid cluster descriptions (value 1 followed by 4096 bytes). Seeing the sequence 0x11b74c22, 0x11b75c23 (error), 0x11b76c24, 0x11b77c25 and 0x11b78c26, which would designate a valid sequence if the byte at 0x11b75c23 would be a 1, I would suggest the error is simply getting a 0 there instead of the expected 1. For rescuing the image, I would suggest : 1) check that there is indeed a 1 byte at offsets 0x11b74c22, 0x11b76c24, 0x11b77c25 and 0x11b78c26 and that there is a zero byte at offset 0x11b75c23 2) if so, insert a 1 at 0x11b75c23 and retry. Of course better make another copy of image before that... Note : better retry with variant 1 which gives an immediate error, and stracing may help if there are other similar bugs. If successful, I will ask you later to do another backup to try to identify the source of the corruption. Regards Jean-Pierre ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
