| View previous topic :: View next topic |
| Author |
Message |
gazurtoids
n00b
Joined: 02 Apr 2003
Posts: 14
|
 Posted: Tue Dec 09, 2003 8:28 am Post subject: OO.o Doc Ascii FTP Disaster - solution needed urgently. |
 |
|
Hi all,
I was transferring a bunch of files by ftp. I sent everything over to the remote server before realising it had all gone over in ASCII mode. I then tried to send all my openoffice documents over in BINARY mode... but instead of typing "mput *.sxw", I typed "mget *.sxw" thereby obliterating my originals with the newly borked copy.  
I now have several OO.o docs (well, zip files effectively), that have transferred via ascii mode so won't open or unpack properly. Is there any way whatsoever that I can recover these documents, even if it's just the content.xml file from the zip? I've trawled google and all I find is a lot of pages telling me (helpfully) in big bold text "Alway transfer zip files in binary mode".
I'm desperate to get these files back if someone can help. |
|
| Back to top |
|
 |
gazurtoids
n00b
Joined: 02 Apr 2003
Posts: 14
|
| Posted: Tue Dec 09, 2003 10:10 am Post subject: |
|
|
More info:
| Code: |
Archive: a2.zip
error [a2.zip]: missing 42 bytes in zipfile
(attempting to process anyway)
error [a2.zip]: attempt to seek before beginning of zipfile
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
(attempting to re-compensate)
replace Pictures/100002000000001200000012EA5D6875.gif? [y]es, [n]o, [A]ll, [N]one, [r]ename: n
replace layout-cache? [y]es, [n]o, [A]ll, [N]one, [r]ename: n
file #3: bad zipfile offset (local header sig): 1164
(attempting to re-compensate)
file #3: bad zipfile offset (local header sig): 1164
file #4: bad zipfile offset (local header sig): 8150
file #5: bad zipfile offset (local header sig): 9656
file #6: bad zipfile offset (local header sig): 10879
file #7: bad zipfile offset (local header sig): 12055
|
Since the output refers to a bad offset is the problem simply that it doesn't know where to look for the component files? I presume the offsets indicate how far into the zipfile (in bytes?) each file is so is there a way to determine the proper value by trial and error? |
|
| Back to top |
|
|
gazurtoids
n00b
Joined: 02 Apr 2003
Posts: 14
|
| Posted: Tue Dec 09, 2003 10:53 pm Post subject: |
|
|
Shameless bump here!
I've been trying to pull the content.xml file out using Archive::Zip in perl but I'm not having much luck. Increasing the offset by 42 (the number of missing bytes) gets the first two files out but some information appears to have been stripped out of the content.xml section so it won't inflate. If I know what the ASCII mode transfer does to the file, would I be able to work out what the missing info is? What is the difference?
Is this even solveable? |
|
| Back to top |
|
|
abiczo
n00b
Joined: 05 Nov 2003
Posts: 6
Location: Budapest, Hungary
|
| Posted: Wed Dec 10, 2003 9:55 pm Post subject: |
|
|
I did a little test. I uploaded a file in ascii mode and then retreived it in binary mode. What I found is that the 0x0a bytes were missing.
Since you also reported that some bytes are missing I guess it's impossible to 'repair' your zip files.  |
|
| Back to top |
|
|
gazurtoids
n00b
Joined: 02 Apr 2003
Posts: 14
|
| Posted: Wed Dec 10, 2003 10:20 pm Post subject: thanks anyway |
|
|
| Yeah, I've pretty much given up hope myself now. I was hoping that the missing bytes would be part of a pair that always appeared together, like a CR and a LF being reduced to just a CR or something. Thanks very much for your efforts though abiczo. |
|
| Back to top |
|
|
|
Desktop Environments
