karn@FALINE.BELLCORE.COM (Phil R. Karn) (09/14/87)
A lot of new FTP users (and some veteran ones, too) get bitten by forgetting to say "type image" before sending a binary file. You get no warning when you do this; you don't discover your mistake until you're done and find that the file is corrupted. I would like to add an advisory message to my own FTP server to warn the user when he/she does this. The FTP client should just display this message to the user but otherwise ignore it, relying on the user to abort the transfer. But how should I do this? I seem to remember that there are reply messages of the "0XX" class that would do what I want, but I can't find it mentioned anywhere in the specs. Comments? Phil
karn@FALINE.BELLCORE.COM (Phil R. Karn) (09/15/87)
Thanks, Ron, yours sounds like a good idea. I'll do it that way. Phil
ron@topaz.rutgers.EDU (Ron Natalie) (09/15/87)
DO NOT ADD 0XX CLASS MESSAGES. They don't exist and some machines
sent them in the past which causes the sequencing of all future
replies to get messed up. The best bet is for the SERVER to just use
different text to the 150 message that is printed just before the
transfer (UNIX usually places the file name and the size of the file
in bytes here). You can make it say something like
150 Starting "foo.bin" IN ASCII MODE
-Ronrick@SEISMO.CSS.GOV (Rick Adams) (09/15/87)
ftp contains a "SITE" word that is largely unused. It would be really nice if most implementations agreed on what came after the SITE word. E.g. It would be really nice to have the user mode ftp program automatically send "SITE UNIX" (or something along that line) and the ftp server on the other machine return success or failure. Then, if the user ftp got success as an answer, it could automagically set the type to image. If it got back anything but successful, it would do nothing, so no harm would be done. I actually implemented this a few years ago. There was one major problem with it. The TOPS-20 ftp servers always returned success to ANY SITE command. Obviously, this screwed up things royally. I was never successful in getting anyone to admit that the TOPS-20 was broken and to fix it. It's a pity that SITE can't be used. It work work wonderfully in this particular case. ---rick
chris@COLUMBIA.EDU (Chris Maio) (09/16/87)
Rick, > I was never successful in getting anyone to admit that the TOPS-20 was > broken and to fix it. All the TOPS-20 FTP servers I know return a 504 failure reply to a "SITE UNIX" command (in contrast to the UNIX server, which mumbles "Please login with USER first"). On the other hand, you should really be using the SYST command instead (see RFC959). Chris
rick@SEISMO.CSS.GOV (Rick Adams) (09/16/87)
Great. They finally fixed it! The server used to return a 2xx response. Now all we need is for them to produce legal RFC822 date lines... ---rick
A024012@RUTVM1.BITNET (Ross Patterson) (09/16/87)
Rick,
According to RFC 959, the SYST command should be used for
verifying the type of server you're using. It's documented as having
no parameters, and returning as the first word of the response, a
system name defined in the Assigned Numbers RFC (whatever it's called
this week). The SITE command is specifically intended for necessary,
but non-universal, parameters. The only system I've seen that
actually uses it (UCLA's IBM MVS implementation) has 20 different
parameters that it accepts. It can specify the disk on which to store
a file; what sort of disk it is; whether to do tab expansion, and if
so, how wide; disk storage format (record lengths, etc); even that
the next file sent is to be run as a batch job.
My point is that any attempt to standardize the use of the SITE
command is improper. If you want a standard facility, change another
command or add a new one. SITE is for those systems that have other
needs and/or capabilities, beyond the standards.
Ross Patterson
Rutgers Universityrick@SEISMO.CSS.GOV (Rick Adams) (09/18/87)
The SYST command looks cute but in the real world is useless. While I suppose that if you get MVS or VMS or TOPS-20 back from the SYST command it might be useful, if it returns "UNIX" then you really haven't gained anything. The wonderful thing about UNIX is that it runs on almost any hardware. What I really want to know in this example is the packing (and possibly byte ordering) of characters in a word. I don't believe that all Unix implementations are 8 bits = 1 character = 1 byte. I think the C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals with me, but you get the idea) If SITE works (and I'm told that it does finally work), then you could do something like "SITE 8BITBYTES" and decide whether to go into binary mode based on that. SYST might be useful, but since its constrained to returning official system types, it just doesn't cut it for UNIX. --rick
bzs@BU-CS.BU.EDU.UUCP (09/18/87)
From: rick@seismo.CSS.GOV (Rick Adams) >The wonderful thing about UNIX is that it runs on almost any hardware. >What I really want to know in this example is the packing (and >possibly byte ordering) of characters in a word. I don't believe that >all Unix implementations are 8 bits = 1 character = 1 byte. I think the >C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals >with me, but you get the idea) > >If SITE works (and I'm told that it does finally work), then you could >do something like "SITE 8BITBYTES" and decide whether to go into binary >mode based on that. It's not even obvious that the particular operating system was ever germaine, that may have been a false start (as you seem to point out in your example.) An image file between a VAX/VMS and VAX/UNIX system will work in image mode as will a 68K and IBM370, something more abstract needs to be developed to cover the cases. Perhaps an asymmetrical psuedo-bitstring who's bit order and length can be used to infer the architecture? Something like: VAX,NS32k: "10010110 10010110 10010110 10010110" 68K,IBM370: "01101001 01101001 01101001 01101001" PDP10: "(?just 36 1s?)" PDP11: "10010110 10010110" etc. Perhaps it could be optionally presented in Hex or Octal using some suitable escape ("0x9696 9696 9696 9696") if that were desired. This could be prefixed by the OS if desired "SITE UNIX 1001..." and a lot would be known. A better binary number than my example is probably needed, but the idea should be clear. The nice thing about it is the default is easy (don't do image.) The only thing that bothers me (I guess) is that the scientific community might have chosen floating point format to normalize upon. And somewhere down there a whole different project lies. -Barry Shein, Boston University
dyer@spdcc.UUCP (09/18/87)
In article <8709172107.AA16664@beno.CSS.GOV>, rick@SEISMO.CSS.GOV (Rick Adams) writes: > What I really want to know in this example is the packing (and > possibly byte ordering) of characters in a word. I don't believe that > all Unix implementations are 8 bits = 1 character = 1 byte. I think the > C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals > with me, but you get the idea) Puhleeaze. The C/70 has *10* bit bytes and *20* bit words, in 68K-style byte order. As you might expect, IMAGE mode was an exercise in bit manipulation. As to how it packed them together, well, that depended on what version of ftp and ftpd we had released at the time. Luckily, this confusion was never inflicted on customers, only in-house. I remember that the switch between one encoding scheme to another was only slightly less disruptive than the cutover from NCP to TCP... -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer