What's new
TerraForums Venus Flytrap, Nepenthes, Drosera and more talk

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

RAR with CRC error

  • Thread starter Av8tor1
  • Start date
Was the file moved from one place to another say using FTP?
 
xan, thanks for the excellent effort... ugh,
Purdue use to have a public access download link, Ive tried finding it again but doesn't seem to be there anymore

anyone with a ASHS membership? LOL

Dash, yes.... when geocities shut down and all my files got moved to the new server it got corrupted, and yes it was FTP

I really hate losing this, its an excellent presentation and she's one of my fav plant lighting researchers

wahhhhh
 
That is most likely the problem.

The default mode for FTP is ASCII. That means it is in the mode to transfer text files. Text files differ based on the OS. With a Linux/UNIX system, new lines are delimited by an ASCII charater of Hex 10 aka LF aka Line Feed. Windows uses a Hex 13 + Hex 10 aka CRLF aka Carriage Return + Line Feed.

The problem is that when you transfer binary files .DOC, .ZIP, .RAR, etc between two disparate systems without specifying BINARY format, the FTP protocol will attempt to translate the file to the format of the desintation machine. That means if it is transferring a file from UNIX to Windows anytime it sees a Line Feed it will replace it with a carriage return + line feed. That is unless you specify to transfer in BINARY format first.

It gets even weirder when going from mainframe (EBCDIC) to UNIX or Windows, especially if there is PACK data (compressed) in the file.

If the file is still available at the source, use the BIN command prior to the GET command.

The BIN or IMAGE (both are used interchangebly) command tells FTP not to do a darn thing to the file, just send as is.

It is very hard (almost impossible) to repair a binary file once it has been "fixed" by FTP. Since binary files can have a LF or CRLF pretty much in any location trying to switch them back will fix some areas of memory but break others. The only fix is to retransfer the file in binary format form the source. Otherwise, I can attempt to reverse what FTP did. But I am not confident that will fix the issue.
 
I can attempt to reverse what FTP did. But I am not confident that will fix the issue.

kewl, if you get the chance.... but no expectations
Butch
 
It may be off topic (and maybe not) but does this mean that you can not upload videos (or audio) to a website if you use FTP to place your stuff online?

I can upload jpgs just fine but never tried doing uploading any audio or video. I know I can not embed You Tube videos of our interviewed acts on our mags website, I've tried and failed miserably.
 
Not necessarily. I think most GUI based FTP programs detect this for you. Some may even be set to binary mode by default, it really depends on what you are using. The standard command line FTP programs shipped with most operating systems use ASCII as the default.

I am just going from experience here. I used to manage data communications for my company when I was just out of college. This is the one of the most common issues I have seen when using FTP, the other is a partial file due to an incomplete transmission.

The way to tell which issue it potentially is would be to compare the file you have to the size of the file at the source. If it is smaller, then it is a partial file. If it is off by a few bytes (greater or smaller) and you are having problems extracting, decrypting, etc then odds are it was sent using ASCII when it is a binary file.
 
Back
Top