Using NT registry calls to solve CR-LF issue with text files.

[Beau Kuiper]

On Mon, 07 Feb 2000, you wrote:
> Beau Kuiper <ekuiperba at cc.curtin.edu.au> wrote:
> >
> > On Sun, 6 Feb 2000, John E. Malmberg wrote:
> >
> > > The mention of looking up performance data from the registry gave me an
> > > idea.
> > >
> > > With the registry calls that you can do now, is it possible or practical
> to
> > > look up the file type in HKEY_CLASSES_ROOT before it is transferred, and
> if
> > > it is registered as a known text type to translate the CR-LF information
> as
> > > the file is being transferred?
> > >
> > > Just a thought.
> > >
> > A very evil thought. They tried to do that with the linux msdos filesystem
> > support. It really stuffed life up for many people with scilent data
> > corruption. To do the same with samba would be not to learn from the
> > mistakes of others. to be specific: YOU CAN NEVER DETERMINE WHAT IS STORED
> > IN A FILE GIVEN THE NAME OF THE FILE :-)
> 
> Windows actually uses two methods of determining a file type.  The first is
> a registry, and the second is to examine the first two bytes of the file for
> a signature.  Some programs use the signature over the file type.
> 
> Somewhere there is a list of these magic codes, but I can not recall where
> it is at the moment.  This is how programs like WORD, WORDPAD, and WRITE
> determine how to translate a document.  I am not sure if there is a master
> list somewhere that Windows maintains for these signatures, or if they are
> hard coded into each application as needed.
> 
> If someone does know of a good reference for these signature bytes that is
> available on-line, on Technet, or MSDN, I would like to know where it is.
> 
> 
> It would certainly be evil if it was manditory, but it could be very useful
> as a per-share option.  And definitely not the default option, but there for
> system administrators to enable after they have read the warnings.
> 
> Even with reading a table from the Windows registry there could be problems.
> On OpenVMS a file name xxxxx.COM is a text shell script.  On Windows, it is
> a binary executable.  This is where the magic codes could be of some help.
> 
> As for my situation, with the OpenVMS operating system, If I do not do some
> translations, I can not pass most text files created on OpenVMS to LANMAN
> clients.
> 
> The default native OpenVMS text file format can not be understood by a
> Windows system.
> It is relatively easy to detect some of the text file formats on OpenVMS and
> send them over the wire correctly.  For all others they must be sent as
> binary.
> 
> On sending a file from Windows to OpenVMS, I also need to know / guess how
> to translate the file format, or the file may only be usable by the Windows
> application.
> 
> The only clue to go by that I have easy access to is the file type.  If a
> call was made to the Windows registry, then I would not have to maintain my
> own table.  A database of the magic codes would also assist in this task.
> 
> The reason I bring this up as a platform independent issue, is the
> complaints from people on the regular samba list about this on the UNIX
> platform.
> 
> Remember the average user thinks all this stuff works by magic.

I learn new stuff every day :-). I never knew windows used a second way to
identify files.

Even though this is still "evil beyond all imagination" (TM), it would be quite
useful if it wasn't the default. For example, mud servers could give smb access
to wizards to edit thier code, and the code files would automaticly be converted
between unix-windows formates as needed. In this case the environment is
controlled enough that it could be safe enough to do on the fly translation.

I just forgot VFS support was being created in samba, and paniced too soon,
sorry about that. It would be good if it was create as a VFS module

BTW, the average user doesn't like it when files get corrupted, and this may
could more weird problems than the original problem  (often .TXT files are not
ascii text files, many weird programs I have never heard about use standard
extentsions with non-standard formats), So big, unignorable errors would be
important :-)

Beau Kuiper
ekuiperba at cc.curtin.edu.au