• Please review our updated Terms and Rules here

FTP get command, corrupted exe files that crash computer?

offensive_Jerk

offensive_Jerk

Veteran Member
Joined
Jul 13, 2009
Messages
1,226
Location
Wisconsin
I started playing around with my older machines again after a long hiatus. Had a daughter born and she takes up a lot of free time so I haven't got to play with my junk much. This is why my memory is fuzzy when it comes to what I've done to transfer files.

Anyway, I have a couple machines I started playing around with again, an IBM AT and my Micro Express 386. I had setup a FTP server on my NAS and it works fine with modern machines. However, when I FTP to the NAS and 'get' a exe file like games, they crash and/or hang either system. On my 386, I've even tried a different FTP client in Windows 3.11 and the files transferred this way do the same thing. I've even went so far as setting up a different FTP server on my Ubuntu machine and the files still crash the DOS computer after 'getting' them. It's hard to keep track of what I've all tried, but I'm pretty sure I've tried taking a working game, uploading it to the ftp server, then getting the file back down hangs the system.

In the past I've mostly used the mTCP suite's FTP server and put files on the hard drive with the vintage dos computer being the server because I wasn't familiar with FTP command line. The software I've transferred in previously this way seems to work fine. I should probably test this again but I'm almost positive this way worked.

Sorry if this is hard to understand. Anyone know why this would be? Some sort of unicode issue? I transferred a .ans file and that seemed to read fine although it was very small in size.
 
bin

Issue that command before your 'get'.

FTP is supposed to default to ASCII mode (7 bit). All older implementations do this. Most new ones don't.

Congratulations on your daughter!
 
KC9UDX said:
bin

Issue that command before your 'get'.

FTP is supposed to default to ASCII mode (7 bit). All older implementations do this. Most new ones don't.

Congratulations on your daughter!
Click to expand...

Sweet, all that headache (hopefully) solved with three letters!
Thanks! Yeah, got another little one on the way very soon..... GULP!
 
Well you're blessed to have them and blessed to have them so close together. You probably won't think so, but those of us with children far apart in years aßure you that you are blessed.
 
So far so good, “bun” seems to be doing the trick! Was able to copy and play some games that would crash. I figured it had to be some encoding type problem.
 
Basically, the reason for the mixup is that ftp is an ancient file transfer protocol that was (IIRC) initially deployed on Multics. When it was introduced, ASCII wasn't yet the most common character code--you had EBCDIC (which was probably more common) and various manufacturer-proprietary codes, so ftp was pretty much a jack-of-all-trades at remote file transfer and attempted to accommodate differences in character representation between computer systems (covered in RFC 114).

Fast-forward to the 1980s, where you had Unix-based machines that used ASCII and terminated line endings with a line-feed (hex 0A). Then there was DOS and CP/M, which used a carriage-return/line feed pair as a line end (hex 0A 0D).

Unless ftp auto-detects the same kind of system (Unix or DOS/Windows) on both ends, it attempts to make peace by performing line ending translation. Unfortunately, executable and other image files are not character strings, but raw binary data. So, in many cases, where it's not clear, you have to indicate binary data to ftp with the "binary" command, which turns off the character translation.
 
It probably was Multics, because it sure wasn't Unix. Thankfully, FTP just doesn't do things the Unix way. Every command being a simple file pipe is handy a lot, but not always.

I'm just surprised that a modern ftp server doesn't start out in bin mode. All the ones I have do, which bugs me. It took decades to get to the point where I don't ever forget to switch to bin mode when I need to anymore. Now I have to go about it the other way round.
 
Thanks for the explanation.
Brings up another question, so when should I not worry about using the bin command? Windows 9x up? Modern Linux?
Are there negatives to always using bin? Should I only use on dos? I’d hate to transfer a bunch of stuff only to find out the data is hosed at some later date.
 
offensive_Jerk said:
Thanks for the explanation.
Brings up another question, so when should I not worry about using the bin command? Windows 9x up? Modern Linux?
Are there negatives to always using bin? Should I only use on dos? I’d hate to transfer a bunch of stuff only to find out the data is hosed at some later date.
Click to expand...

When in doubt, use bin. Data in: data out. Garbage in: garbage out. The only time to use ASCII mode is when you are transferring a known plan text file, like /etc/hosts. And then, the only time you actually need to is when you're transferring files between operating systems that differ in the way they terminate text lines.

Unix, Amiga, Linux, QNX, and anything workstationy all use #10 LF.
Commodore and Apple 8-bit systems, as well as pre-OSX Macs all use #13 CR.
CP/M, MSDOS, Windows, and anything else that really follows the ANSI scheme, all use #13#10 CRLF.

Even then, when in doubt, just use bin. You can always convert any files that you need to later on.

Maybe Chuck(G) knows this: Does ftp do EBCDIC to ASCII conversion?
 
It depends on the implementation. GNU ftp can certainly do this--see the "type" command.

I suspect that simpler ftp programs don't make the provision for differing character sets.

IBM ZOS/MVS ftp appears to have a very flexible type command in their version of ftp.
 
Last edited:
Thank you, Chuck, for looking into that. I feel kind of stupid though because I discovered I have documentation on this.

And I'm for some reason happy to report that all my Amigas and NetBSD machines support EBCDIC, type E. My Raspbian and Windoze machines do not. Now I have another way to seriously corrupt files that I never thought about before.
 
Interesting! RFC 114 explains that FTP was developed to work between Multics and PDP-10 systems at MIT.
 
Yup--most people think of ftp as a Unix thing, but in fact, it slightly predates Unix.

On 16-bit and higher systems, it's a fixture if you've installed networking, although I've run into a few Linux/BSD variants that default to ftp-over-SSH implementations (i.e. you have to find your own plain old ftp client). I've never investigated if ftp was implemented in any 8 bit CP/M systems--it would be interesting to find some implementations.

SMTP, by comparison is relatively recent (1982).
 
Such a distinction is meaningless in my view. Unix is a scaled down version of Multics. They're not the same, but inextricanly intertwined. As I recall none of the 6 days of creation mention Unix.
 
You're entitled to your own views. I found little in common between Unix and Multics from a user's standpoint. Multics certainly influenced Unix, but Unix is not Multics--and that's a good thing. Multics, as innovative as it was, was a huge resource hog when hardware cost real money. Probably the biggest similarity is the file system.

I recall visiting a friend who'd just transferred to work at the newly-acquired-from-GE plant in Phoenix in the early 70s. I was expecting to see a lot of Multics-related stuff. I saw GE 600-series mainframes mothballed for reference, and although folks had heard of Multics, the OS work was GECOS/GCOS.
 
And GECOS influenced Multics. What's your point? CP/M grew out of OS/8 arguably.

It was a small world then, with lots of operating systems. Doubtless you can find many commonalities in many of them.
 
Have you read up on Multics? The very common story of the writers of Unix first writing Multics and then deciding it was useless is baloney. So is the story that Multics didn't last very long. The last Multics update was 1992, not 1972.

The two guys who wrote Unix wrote applications for Multics, not the OS. Sure they were influenced by Multics, but then everything since then has been by about the same amount. But Unix is not very much like Multics at all.
 
Personally, I've always had a lot of admiration of Burroughs/Unisys MCP/Clearpath. Still around after more than 50 years.

It does require special hardware, which is probably the only big drawback.
 
You must log in or register to reply here.
Back
Top