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]>