[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1654
  • Last Modified:

FTP - ascii versus binary

IF I ftp a file without using bin (ftp from Unix to XP),  is the file then corrupted (it was an Oracle export).

If YES, is there a way to uncorrupt the file (conversion program or something).
0
booksplus
Asked:
booksplus
  • 4
  • 2
  • 2
  • +5
5 Solutions
 
Jeff BeckhamEngineerCommented:
If you've used ASCII to transfer a binary file, it is corrupted and is not repairable.
0
 
booksplusAuthor Commented:
Is Oracle export a binary file.
0
 
Juan OcasioCommented:
It should be a binary file.  If you still have the file you should export it as binary.  As jebeckham said, you cannot ftp a binary file using ASCII method without corrupting the file.  What happens is it tries to translate the binary data into ASCII...

0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
r-kCommented:
The main difference between transferring in Ascii and Binary mode is that in Binary mode, the file is transferred intact and unchanged, while in Ascii mode, extra characters such as line breaks and carriage-return characters are added to the destination file. (I know this is somewhat simplified, but in this case it is enough).

So, assuming your file really was binary to begin with, and you used ascii mode ftp, what you end up with is a file that is slightly bigger than the original, with all these extra characters added after every 80 bytes or so. The important thing to note is that ascii version contains everything that was in the original, plus more.

So in principle you can strip out the extra characters and get the original binary file back.

As the others have suggested, it is much simpler if you can simply re-transfer in binary mode. However, if that is not possible please post back and I'll post further tips on how to recover the file.
0
 
giltjrCommented:
r-k, please read the ftp RFC.  What you are stating is wrong.  http://www.faqs.org/rfcs/rfc959.html

There are NO extra characters added every 80 bytes or so.  When transfering in ASCII mode the sender and the receiver assumes that the file contains text only.  It will change the native record termination charaters (LF in Unix's case) to CRLF for transmission and the reciever will replace the CRLF with its native record termination character, which in this case just happens to be CRLF.

So every place there was LF in the oringally binary file, Windows will have a CRLF.  The problem is you can't just strip these out, as you have no clue if the original binary file may have just had a CRLF in it to begin with.  Which means what started out in a binary file as CRLF is now CRCRLF on the Windows side remember Unix change the LF to CRLF.

So if the original file contained LF or CRLF the new file now contains CRLF and CRCRLF.  You can't strip them out, you might be able to write a program that replaces all CRLF's with just LF and hope for the best.  However their may be other changes as technically the sender changes the character format whatever it stores its text data in nativly to NVT-ASCII and  the receiver is supposed to change the NVT-ASCII to its internal format.  There maybe other things that got changed.
0
 
r-kCommented:
"What you are stating is wrong.."

Simplified yes, but not wrong. If you read my original post more carefully, you will notice that I used phrases like "somewhat simplified.." and "..or so" and "..in principle". Your elaboration is in fact repeating what I said but pointing out the main problem, i.e. if the original binary file happened to contain CR/LF characters by chance, then recovery becomes difficult. That is why I recommended to the original poster that getting the original file sent again is the best way.

However, my statements are not just theoretical. Some time back I was called upon to write a program to fix this exact same problem (though the files were not from Oracle), which I did, and the data were restored in 100% of cases. It is true that you need some knowledge about the files, esp. you need to be able to check that the recreation was successful.

So what I am saying is that while not guaranteed, it is possible. If there are other ways to get the files restored that is certainly better.
0
 
giltjrCommented:
I would say that you got lucky.  The NVT-ASCII standard uses 7-bit ASCII but transmitts the data using 8 bits.  The problem is that execpt for specially defined control charaters the msb is supposed to be set to 0 in all cases for values greater that decimal value 128, so x80 becomes x00.  Which means that if you have any data that is decimal values of 128-255 that do not represent the defined control characters, you will loose the msb and thus have garbage.  The majority of the special control characters are decimal 240-255, which means anything between 128-239 gets changed.

See http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html for reference and/or search on "NVT-ASCII msb" using any search engine

If you were able to create a program to fix a file that had been transfered with ASCII and it should have been BIN and you were succesful, then I would say that the file was in a sense ASCII, that is it only contained only characters with hex vailues 0-7F.
0
 
ppfoongCommented:

Always use binary transfer to all non-plaintext file.


0
 
r-kCommented:
"I would say that you got lucky...."

Luck has not much to do with it. In fact almost none of the FTP implementations strip out any of the bits in ascii mode. Rather than worry about what is supposed to happen, you can easily test this by transferring a few binary files (e.g. images or movies) in ascii mode using ftp and see what happens. I just did this with three different FTP servers, and no bits were lost in ascii mode.

In any case, I am not much interested in debating this point. I will wait for the original poster to get back with more information if he has an interest in restoring his file. It would help to know something about which systems the file was transferred from/to, and using which FTP server/client?
0
 
booksplusAuthor Commented:
I performed the process over again.  Which meant that I had to fedex an external hard drive again - the file was 7 GB.  This time a ftp'd the file in binary mode.  

Thanks for all your input.  Very good discussion.  I may post a new topic to find out how to repair the file for future reference.
0
 
r-kCommented:
Thanks. Glad you were able to recover your file.
0
 
olmyCommented:
Dear R-k

I'm trying to reach you, since I have a broken binary that was transfered in ASCII mode.
http://www.experts-exchange.com/Software/Internet_Email/File_Sharing/FTP/Q_22954045.html#a20270092
0
 
lbukysCommented:
Binary files transferred in ftp ascii mode experience loss of information.
Depending on what kind of file it is, recovery can be anywhere from easy to difficult to impossible.

The accepted answer is usually the best one -- re-transfer, taking care not to corrupt the file with ftp "type ascii".

Easy: Plain text files, some straightforward CR/LF munging restores what you need.
Difficult: I have successfully recovered data in corrupt zip files, but the process is not turn-key, it requires lots of computation, and it requires a heavily modified decompressor, and custom coding of a search heuristic function.  So every case is a consulting project, not a turn-key process.  But if you've lost something important and irreplaceable, maybe it's worth it.  I have a web site http://www.bukys.com/services/recovery/ that describes the services, for those rare cases where this is the right solution.
Impossible: If your can't describe something about your data that can guide the repair process (e.g. it's not very structured) then it really is infeasible to fix it.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 2
  • 2
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now