Bruce wrote:
> Chris Breemer asks:
>
> >1) How does one get around the CR/LF difference ? Files on MPE created
> >   by Samba now get CR/LF instead of just LF. Conversely, because of
> >   missing CR's, MPE files are not displayed correctly by Notepad
> >   (Wordpad does them just fine though).
>
> This is one of the joys of using a mixed environment. There's no way to
> get around it without either (a) using tools that don't care about the
> difference between line terminations, or (b) using a conversion program.

One of the "Posix-Smoothing" enhancements I've suggested to HP is that
they add a couple of bits to the MPE File Label to indicate which of
the three line terminators we *think* the file uses (Unix=LF, Mac=CR,
DOS/WIN=CRLF).  Additionally, the current MPE feature of automatically
making LF delimited "UNIX style" text files look and act like MPE
Variable Length files can be extended to look at this new file attribute,
which would make it possible to correctly process these files in many
more existing MPE applications.

This would give us a way of permanently associating with a file the
information about which style of record delimiter it uses.  Once this
is available, all kinds of tools can be taught to handle all three
common styles of text file.  This would make MPE one of the most
friendly operating systems for file serving and processing.

It might be possible to teach the Posix C runtime library that if you're
asking for a file as a text file, that it should automagically translate
the file appropriately when reading and writing.  This could make every
Posix program on the 3000 able to handle any text file from any client.

One way this feature would be used is that when a server-type program
stores a file on the 3000 on behalf of a client, it would set the new
flag to the value appropriate based on whatever knowledge it has, which
is probably limited to knowing what type of client it is talking to.
Samba could set the flag to the "CRLF" value for all files it creates
on behalf of Windows clients for example.

So now we have the ability to use this information (optionally) when
reading the file.  Since we haven't tried to translate the file contents
in any way, we haven't had an opportunity to corrupt the file as would
be the case if the server tried to "intelligently" translate ASCII files
to LF format when stored on the 3000, and back to the appropriate format
when serving the file up to a non-LF type client.  The worst thing that
will happen is that if we want to serve a file to a client that uses a
different line terminator than the client that created the file, we
might inappropriately perform a conversion on the file when serving it.
In this case you would have to take some action to force the transfer
to disable the translation, but at least the data would then be available
in an uncorrupted state.

Comments?

G.