Subject: Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)
From: [email-masked] (Scott Blachowicz)

8 Jan 1998 16:43:27 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
To: "Jeffrey C. Fried" <[email-masked]>
Cc: "Earnie Boyd" <[email-masked]>, [email-masked]

"Jeffrey C. Fried" <[email-masked]> writes:

> from both operating systems under NT/95.  For examples of this
> compatibility look at many of the GNU tools which handle text, the file
> handling will work under both operating systems without any change because
> they use text mode I/O which is platform independent once all files have
> been converted to the form of the native OS.

A problem is that the open() call in MS-land has a binary/text mode flag,
but Unix open() calls generally don't (since there is typically no
binary/text mode distinction made).  So, you always end up having
problems with porting arbitrary Unix code over to MS-land when the Unix
code calls open() without specifying a mode AND the default mode doesn't
match what the Unix code was expecting.

Part of the problem with specifying the default text file type on a
per-mount basis is that it frequently isn't the right basis for specifying
it.  I may have mounts where I want both style of line termination - maybe
it's more related to what kind of file I'm writing.  Using the mount point
is kind of a best guess heuristic, I guess.  What we need is omniscent
software that just knows what I want and does it :-)).

Maybe it'd be nice of the mount mode were irrelevant when reading an
existing file, but just controlled what happens when you write a file to
the file system.  Maybe the reading operations could track what kind of
line termination is being used on a file, then succeeding write operations
could use the same style (unless overridden by the open() flags)?  That
sounds weird...and probably unworkable...just food for thought.

How do the MS-land programs that understand both line terminations work?
They probably just accept either on input, then do \r\n on output, right?

Oh, Idunno...
-- 
Scott Blachowicz                <[email-masked]>

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".