Hi again,

Jean-Pierre André wrote:
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.

I have attached a patch to ntfsclone to check for
a non-zero count of clusters to skip, display the
location of such corruption, and abort.

Please try.

Regards

Jean-Pierre

Attachment: error-location.patch.gz
Description: GNU Zip compressed data

------------------------------------------------------------------------------
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

Reply via email to