- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Verifying FTP'ed file whether transferred in b...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 03:05 PM
тАО02-05-2009 03:05 PM
If a text file is created on windows and transferred via ftp using binary mode then we see ^M characters at
the end of each lines when opened in Unix.
I noticed if we transfer text file using ftp via ASCII mode then this ^M characters are not visible when opened
in unix vi editor.
Windows and unix text file has different end of line characters.
So why not ^M characters are observed when text files are ftp'ed from Windows to Unix
in ASCII mode ?
Second question:
If file is binary then how to verify whether it was transferred via ftp using correct binary mode ?
Thanks,
Shiv
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 03:12 PM
тАО02-05-2009 03:12 PM
Re: Verifying FTP'ed file whether transferred in binary or ascii mode
FTP transfers that invoke ASCII mode are designed to add/subtract the carriage-return characters used on platforms like Windows as files are moved from UNIX to Windows or vice-versa. THe behavior you see is expected, desired and correct.
If you transfer in BINARY mode, no attempt is made to adjust the end-of-line character(s).
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 03:28 PM
тАО02-05-2009 03:28 PM
Re: Verifying FTP'ed file whether transferred in binary or ascii mode
More accurately, fiddling with a binary file will corrupt a data file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 04:23 PM
тАО02-05-2009 04:23 PM
Re: Verifying FTP'ed file whether transferred in binary or ascii mode
> Dennis: More accurately, fiddling with a binary file will corrupt a data file.
If one is only transferring a file via FTP in Binary mode, no "fiddling" should occur. If one attempts to 'vi', use 'sed', 'awk' or Perl to munge a binary file then (perhaps except for Perl's abilities) you are indeed likely to mangle what you munge.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 05:58 PM
тАО02-05-2009 05:58 PM
Re: Verifying FTP'ed file whether transferred in binary or ascii mode
That's what I meant. The binary command doesn't fiddle with the data, ascii does.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 07:52 PM
тАО02-05-2009 07:52 PM
Solutionftp is a very powerful file transfer tool and is portable to many different systems. Windows and Unix are trivial examples. An ASCII file on a mainframe can be a dozen different formats including fixed line widths with no trigger character for the end of line at all. ftp's ASCII mode actually neutralizes (removes the file's internal codes) each record on both ends. Then the record is transmitted and turned into the appropriate format at the destination.
Windows mandates that a plain ASCII file has CR+LF at the end of each record. Unix requires just LF. RTE (the HP 1000) requires a 16bit number containing the length, followed by the text and then followed by the length again. Mainframes and other business machines also have specialized codes.
Although you saw ^M in vi or cat -v, what you did not see is the black spot in Windows when you send an ASCII file from Unix to Windows using binary. Notepad will show this black spot because the 2-character CR+LF is not there. If you open the file in Word or Wordpad, it looks normal but the LF by itself is defined a soft carriage return. This has a different meaning than a hard carriage return (CR+LF) for word processors.
So ASCII is a very specific translator and should only be used with true ASCII files. BINARY turns off all translation and sends exactly what in the source file. Whether this is useful on the destination system depends on what is in the file and the process used to read it.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2009 08:01 PM
тАО02-05-2009 08:01 PM
Re: Verifying FTP'ed file whether transferred in binary or ascii mode
A secondary script can use the file command against it. The list can be gathered with a find +mtime command.
Or use sftp and stop caring. Secure shell always gets it right.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com