Over the weekend, I started with the best of intentions to collect information on Posix file system quirks to build a web page on Opus as a guide to transferring files via FTP/WWW/downloads to the 3000. As I result, now I'm thoroughly confused myself (again) just when I thought I had things figured out. I was trying to illustrate the effects of fixed, variable length, and bytestream files and their behavior. To that end, I tried an example of creating a simple, one-line text file in each format. I entered the text "This is a test file" in EDITOR and kept it fixed and variable as TEST1 and TEST2. Then I used vi to create a similar file under the shell. The resulting LISTF indicates: FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE---- SIZE TYP EOF LIMIT R/B SECTORS #X MX TEST1 72B FA 1 1 3 16 1 1 TEST2 1276B VA 1 1 1 16 1 2 TEST3 1B BA 20 2147483647 1 16 1 * TEST1 and TEST3 are as expected; TEST2 is rather confusing as to why it chose 1276 bytes as a record length. It isn't a multiple of 72, even with record length/block length fields added in; but does fit in a 1280 byte block (why 1280? why not 1024 or 4096 to assist paging?) That wasn't a big deal. But on to the shell. The files look like: shell/iX> ls -l total 5 -rwx------ 1 MANAGER.SYS SYS 72 Jul 1 10:58 TEST1 -rwx------ 1 MANAGER.SYS SYS 1280 Jul 1 10:58 TEST2 -rw-rw---- 1 MANAGER.SYS SYS 20 Jul 1 10:22 TEST3 This makes some sense, we can extrapolate the 1280 easily enough, and clearly it can't show the true bytestream-equivalent length without actually feeding the file through the bytestream emulator. The first real surprise was in the shell, reading the files with the "cat" utility. The non-bytestream files have no newline character! :/bin/sh $ cat TEST1 This is a test file$ $ cat TEST2 This is a test file$ $ cat TEST3 This is a test file $ cat TEST1 TEST2 TEST3 This is a test fileThis is a test fileThis is a test file $ cat TEST3 TEST2 TEST1 This is a test file This is a test fileThis is a test file$ Note the sh prompt immediately follows the text of TEST1 and TEST2, but not TEST3. The final options illustrate (as expected) that the trailing blanks of TEST1 are stripped, but still, no newline in either TEST1 or TEST2. MPE sees them all the same: :print test1 This is a test file :print test2 This is a test file :print test3 This is a test file : Now the real kicker... I logged onto a Unix box and FTP'ed the files in ASCII mode. The results: unixbox.utc.edu% ls -l test* -rw------- 1 jeff staff 73 Jul 1 10:45 test1 -rw------- 1 jeff staff 20 Jul 1 10:45 test2 -rw------- 1 jeff staff 40 Jul 1 10:45 test3 unixbox.utc.edu% cat test1 test2 test3 This is a test file This is a test file T h i s i s a t e s t f i l e unixbox.utc.edu% TEST3 was a major surprise. Is this a bug? If it isn't, it should be in my opinion. FTP isn't very Posix-friendly as it is, but this is pretty bad. Granted if you transfer in BINARY mode it will work for this case (TEST3) but you shouldn't have to do that, it makes no sense. At any rate, I can't do a helpful WWW reference page until I can figure this stuff out myself :-( [\] Jeff Kell <[log in to unmask]>