DeviceImage Tools Forum Index DeviceImage Tools
Forum to discuss all about device-image tools
 
 FAQFAQ   SearchSearch   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Restore error in accessing input file

 
Post new topic   Reply to topic    DeviceImage Tools Forum Index -> Using localy
View previous topic :: View next topic  
Author Message
Guest
Guest





PostPosted: Mon Oct 24, 2005 12:22 pm    Post subject: Restore error in accessing input file Reply with quote

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?
Back to top
jurij
Site Admin


Joined: 05 Apr 2005
Posts: 54
Location: Germany

PostPosted: Mon Oct 24, 2005 9:11 pm    Post subject: Reply with quote

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:
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jurij
Site Admin


Joined: 05 Apr 2005
Posts: 54
Location: Germany

PostPosted: Tue Oct 25, 2005 4:23 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Guest
Guest





PostPosted: Wed Oct 26, 2005 8:44 am    Post subject: Reply with quote

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.
Back to top
jurij
Site Admin


Joined: 05 Apr 2005
Posts: 54
Location: Germany

PostPosted: Wed Oct 26, 2005 9:11 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Guest
Guest





PostPosted: Thu Oct 27, 2005 9:47 am    Post subject: Reply with quote

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
Back to top
jurij
Site Admin


Joined: 05 Apr 2005
Posts: 54
Location: Germany

PostPosted: Thu Oct 27, 2005 11:27 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    DeviceImage Tools Forum Index -> Using localy All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Board Security

206158 Attacks blocked

Powered by phpBB © 2001, 2005 phpBB Group