DeviceImage Tools

[Guest]

Hi, I'm backup up a NTFS partition on a SATA drive to a Samba share. Making the image works like a breeze. I got my hopes up since partimage couldn't do the job.

Restore however generates the following error:

./unzsplit /mnt/mydir/D380_origineel_0 -d -D /dev/sdb

24-10-2005 13:17:46 unzsplit: version: 1.2.0
24-10-2005 13:17:46 unzsplit: start of operation
24-10-2005 13:17:46 unzsplit: read/write buffer size: 64 kibibyte (65536 bytes).
24-10-2005 13:17:46 unzsplit: inflating D380_origineel_0.spl.zp
24-10-2005 13:17:46 unzsplit: error in accessing input file: D380_origineel_0.spl.zp, in: treat_file()
24-10-2005 13:17:46 unzsplit: not succeeded..., error in operation!
24-10-2005 13:17:46 unzsplit: end of operation

Tried it on two identical machines. Same error. Is there a rights issue or something? I'm logged in as root, rights on the unzsplit executable and the image file for me are rwx, shouldn't be a problem, right?

Is it a bug or am I doing something very stupid?

[jurij]

Hi,

First, I have thought there was an error in the right order of input parameters, but your version should work ok. This error says that the file you are going to restore, in this case this is:
[b]D380_origineel_0.spl.zp[/b], is not accessible for the stat function. Before unzsplit tries to open the appropriate file, it first checks it in order to find out is this file accessible or not. If this file is not accessible, this error message arises. Please check if your path and filename are ok. As you have full access rights for these image files, access rights should not be a problem for this case. I think, unzsplit simply cannot find the first chunk of your image (path or image-name could be wrong).

Please feel free to post here your solution or other questions, I will do my best to find a solution for you.

By the way you can use image name as [b]D380_origineel[/b] without a digit, unzsplit should find out all chunks and the right read order automagically.

Regards,
Jurij :wink:

[jurij]

Hi,
Some additional thoughts to your problem..
What I do not understand is: the zsplit, before access check, tries to find out names of all chunks in the provided path. If some inconsistency was found: in the order of chunks or no beginning part found, the program exits with appropriate error message. In your case unzsplit obviously can find all chunks and see that all chunks could be written in the right order. Therefore the program goes farther and tries to access the firs chunk … and here there is no access to this file… It seems for me like in the last moment the first chunk is disappeared from the directory were it should be.

My suggestion, could you give me the list of all chunk names produced with zsplit in this case. I could only imagine there is a problem with names of chunks and unzsplit could not manage this situation.
The next possibility is the following: the file chunks reside on the file-system which is not fully supported by linux.

Please provide me with more information on this metter.

Regards,
Jurij

[Guest]

Hi,

Thanks for your feedback. Stat'ing the file gives this result:

File: `/mnt/mydir/D380_origineel_0.spl.zp'
Size: 1371106024 Blocks: 2677942 IO Block: 4096 regular file
Device: dh/13d Inode: 317 Links: 1
Access: (0744/-rwxr--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2005-10-24 11:10:58.000000000 +0000
Modify: 2005-10-24 11:10:58.000000000 +0000
Change: 2005-10-24 09:21:53.961487100 +0000

The image is located on an NTFS network share I'm accessing through Samba. (mount -t smbfs etc.) could it have something to do with that? I created the image like that too.

If by chunks you mean image files, I only have the one D380_origineel_0.spl.zp. It's 1.3gig's.

Please let me know if there's any other information I can provide that'll make things clearer.

[jurij]

Hi,

Its very, very strange. If you try to access this file with stat, it works… If the same stat function call occurs inside the program … it is not working…. Hmm… We should make some tests here in order to find out what is wrong in your case. I think we have here following candidates which can produce error in access: timing problem (because it could be slow response over the network and stat call cannot return 0), samba/NTFS (but I think the probability that here could be something wrong is very small, because you could successfully write an image previously).

Try the following: insert the NTFS drive in your computer were Linux runs. Mount partition were your chunk (D380_origineel_0.spl.zp ) resides (mount –t ntfs /dev/xxx1 /mnt/ntfs). And try with restoring locally. If this works, then it is definitely problem of stating over the network. Than I should see may be it is a good idea to implement here some sort of timeout.

Thank you in advance,
Jurij

[Guest]

I tried it. Hooked up another NTFS hard drive with the image on it. Not the one I originally wrote the image to since that was in a running file server :-)

But unfortunately I get exactly the same error...

So my next thought was to retry making an image, this time directly to that second hard drive. Making the image worked fine, trying to restore it: same error.

Then I thought that maybe there would be troubles with the drive I'm trying to restore to since it's a SATA drive. (/dev/sdb) And I figured maybe the SATA controller gave trouble. Tried making and restoring an image to that second (IDE) hard drive. Same error.

Any ideas?

Clemens

[jurij]

Hi Clemens,

Ok… this is very important to know. So you get the same error if you do restore over the network or locally. Now we should test if the combination NTFS/samba and/or your Linux-Kernel could produce this error. The next test I would suggest: copy your image or make a new image to one of linux partitions and try to restore from the native linux fs.

Could you provide me with the info about the version of Linux-Kernel you use ?

Thanks,
Jurij