Red Hat

Hello Friends,

I have observed one recent issue about ftp from windows to Linux.

Initially we had Solaris unix and any file sent from windows to solaris via ftp (binary or ascii) worked smoothly.
Say for e.g if I sent a shell script to soalris from windows, that script used to run corectly. So did an encrypted file which got successfully decrypted on Solaris.
Things changed when we got Redhat linux which replaced solaris and now all the above file transfers have caused issues. In that, once the file was successfully transferred to Linux, and if you open the file in Vi editor, you will see [dos] at the bottom. This is not about ^M characters. I assure that files are sent in correct mode. So we dont get ^M chars. Only the [dos] at the bottom when opened in Vim. so the shell scripts having [dos] at the bottom dont run and error out.
The binary files sent via ftp also dont work when ran on Linux.
Thus, all these files run only when dos2unix is ran on them. On text files the [dos] symbol goes away and bainary files get run successfully then.

My question to experts here is, why in solaris, a file which is sent in correct mode from win to solaris does not need a dos2unix processing and why those files need dos2unix processing when sent from win to Redhad or Oracle Linux.

Thanks,
Albert

Most probably because Solaris ftp had a default mode of "binary" whereas Linux ftp has "ASCII" or thereabouts.

ftp (the command, not the protocol) has two modes: "binary" sends files as they are. "ASCII" becomes aware on which system type it runs and translates line-ending sequences to the respectively correct sequence on the target system. I have written a lengthy explanation about what is going on and why which you can read if interested.

Perhaps the Linux ftp can be configured to do the same as the Solaris client did.

I hope this helps.

bakunin

Hi Bakunin,

Thanks for your reply!

But, the mode is not the issue. I have sent the same file from win to Linux in both, binary and ascii modes. In both cases [dos] sign att he bottom of the file when received at linux end says that it has some dos chars.

Sorry if I have missed your actual point which you wanted to convey. But, modes are not the issue as in both the modes we have to run dos2unix on the said file when received on linux.

Believe me, it is.

What do you mean by "[dos] sign" this is definitely not a diagnostic message of the ftp command, yes?

Of course they are, but you have probably not yet identified the culprit. The only thing "dos2unix" and similar tools do is to replace <CR><LF>-styly line ends (DOS/Win) to <NL>-style line ends (UNIX). Use a hex editor on what you call a DOS-file and on what you call a UNIX-file and you will see this exact difference described in the post i linked to above.

Create a test file (in UNIX) of two lines, like this:

Code:

AB
CD

and use this command in UNIX to display it:

Code:

# od -ax /path/to/testfile

then transfer it, so that it is converted to "DOS" mode, then do the same again. You will see the difference easily.

I hope this helps.

bakunin

To my knowledge the [dos] tag in vim says that there are CRLF line endings and the ^M sequences are not displayed.
I remember some time ago the vsftp FTP-server on RedHat ignored ascii mode and always used binary mode, no matter what the client set.

I agree with cero. Redhat says it's doing a ASCII mode transfer but it lies and does a binary mode transfer anyway. I think that you have to force this. Please post the content of /etc/vsftpd/vsftpd.conf

A recent vim, when the majority of lines have <CR><LF>, does not display the <CR>s as ^M, but goes into [dos] mode. New lines will get the extra <CR>. So you can directly edit DOS files.
--
DOS (United States) Department of State
DOS Denial Of Service [attack]
DOS (Microsoft) Disk Operating System