Bruce responds:
> While the flag is unquestionably useful for MPE programs trying to read a
> file, it's of much less value for server programs. A server program that
> tries to do EOL translation for its clients risks corrupting data for
> non-text files.

The flag I proposed at least has the advantage that the server would
never corrupt data when storing it, thus there is less hazard of
permanent loss of data.  The data is saved as a pure binary stream
of data from the client, and the the new record-separator-type flag
is set as an out-of-band notation of what we *think* the record
separator would be *if* it is a text file.  Now whenever Samba gets
asked to serve up that file again, it looks at the flag and sees
that the probable record separator is the same as the one the current
client natively uses (assuming all the Samba clients are Windows)
so it knows that even if the file is a text file, no translation is
required.  Only in the case of a file with a different record
separator flag does it have to think about possibly trying to convert
the record format.  Here the only decision it has to make is
whether the file really is a text file or not.  There are lots of
less than perfect ways to make this decision, and lots of ways of
allowing the client to override the server's decision (which are
beyond the scope of this posting).

If we have two bits available for the flag, then we have four
possible values; the three common record separators and a forth
value (probably zero) that means unknown/default.  If Samba gets
asked to serve an ASCII BYTESTREAM file with the record separator
flag explicitly set to the "LF" value (the probable result of
saving a text file with an intelligent posix-style text editor
on the 3000) then it can probably be pretty confident that the
file is a text file and should be translated from LF to CRLF
format when being served to a Windows client.

For MPE programs, an editor (vi say) will be able to make good use
of the Record Separator Flag set by Samba (or whatever).  The user
will be able to make the distinction between a binary file and a
text file based on whether they see garbage on the screen or not.

Another option might be to use three bits for the flag.  The extra
bit would indicate whether we think the file *might* be a text file,
or if we *know* that the file is a text file.  This would let a
server provide a hint at the file type which could be upgraded to
certainty through some other process (manual intervention or whatever).

G.