cannot transfer files correctly
 

Hi

I have a number of linux servers that I use.
My development box is REDHAT.
My Live box is REDHAT.
MY internal BOX is DEBIAN WOODY.

My question is: I am trying to transfer files from my development box to my internal box, this can only be done via secure means (scp, ssh, sftp). Everytime that i transfer a file in this direction the file(s) has a ^M symbol at the end of each line ???

I can transfer the file back, and it is fine.

I can transfer a file from any of my other machines to my internal and it is fine.

I can transfer a file from my development to any other than the internal and it is fine???

If i transfer a file from my development to another server, then onto the internal it has the same problem ^M.

I have read about using :%s/^M//g in VI and, yes it does work but is not really a solution as i transfer LOTS of files.

Basically, any file that has been on the Development server and ends up on the internal server is corrupt (for want of a better word).

Does anyone have any idea???

Cheers


p.s Im a real newbie to asking questions so I hope i have explained myself well.

You could encrypt the files by gpg and then use NFS to make the transfer.
The process could even be automated.

Have you tried SSL?

Hi Simon

Thanks for the response, and sorry I am so late in getting back.

I had been called away on more urgent business, but am now looking at it again.

I will be trying you ideas out tomorrow.

BUT what i really want to know is WHY????

Do you have any idea why this is occuring?

Is there some sort of seeting i can use to controll Ascii , Binary (guessing this must be the problem).

Cheers
Steve

My only thought would be that the end line characters are somehow different on each system, or are being interpreted incorrectly. :/

Summary:
^M at the end of each line (ahead of CR (ascii 0xD) I guess?) = X

dev --> int : X
int --> dev : O
any --> int : X
dev --> not(int) : O
dev --> server --> int : X

logically this would be a decryption error on the internal box (running debian).

sftp is ftp over an ssh transport
scp is cp over an ssh transport
ssh is the openSSH client

ssh encryption/decryption should be looked at.

RH (depending) uses tripple-des encryption by default - do not know what debian-woody is using. You should examine the man pages and check ssh version in each machine.

You could try specifying "ssh -c des" to test if this is the problem.

Somehow I doubt it - surely if the 3des wasn't supported somewhere, then the file would decrypt as gibberish! However, comparing how RH and woody handle SSH encryption/decryption would be a good start.

Hi Simon

Thanks for the help.

You got me thinking!
The problem was: I was running DEBIAN WOODY which is the stable version of Debian and the apt-get had only recieved stable version of NANO (the editor I use).
this satbel version of Nano 1.0.? was not capabe of converting from DOS file type.

WHAT I DID:
Incase anyone else has this problem, here is what i did.

I changed the source.list for apt-get in /etc/apt/soure.list to include a testing site
e.g. deb ftp://ftp.uk.debian.org/debian/ testing main contrib

then I ran # apt-get update

then # apt-get install nano

This installed nano version 1.2.4 which now displays the text without DOS ^M at the end of each line.

Then i changed the source.list file back again to the stable addresses.

NOTE: I didn't pick this up straight away because my other servers are DEBIAN SARGE which is currently a testing release and this apt-get got the testing version of NANO.

Also i did a apt-get install sysutils (on stable), this is a group of tools for debian which includes dos2unix or fromdos, both of which are excellent for actually converting the files to Unix type i.e. ^J not ^M.


My solution with the nano upgrade now means I can view and edit the files with no Probs of the ^M being in the way.


Cheers
Steve

Excellent: hopefully you also picked up the technique of isolating the problem. Usually once you know where the trouble lies, you can identify it. ONce identified, the solution often presents itself :)

That's basic scientific method that is.
Good work.