"\r\n" vs "\n" between Unix and Win

[Christopher Robison]

Medi,

Regardless of the actual origin of the problem (a difference in viewpoint
about what a "carriage return" is, back when Unix, CP/M, and DOS were being
developed), I think the real issue here is one of format identification.
Let me try to clarify.

What FTP does, it does because you tell it to.  You select the transfer mode
(binary or ascii); if you've set it to binary, it leaves the file alone, and
in ascii mode it converts each occurrance of a unix newline to whatever is
necessary for your system (eg. cr/lf), or vice-versa. The main point I'm
making is that you have to set this mode.

What you want Samba to do is perform this conversion silently behind the
scenes. In order to do this, Samba would have to look at the file and decide
if it's a text file or not.  On the surface this seems like it might be
fairly simple, though time-consuming -- look at every byte of the file and
see if the high-order bit is set. If they're all zero, it's 7-bit ascii
text, and the routine can go ahead and convert.  Scrutiny reveals all sorts
of problems with this, however. First of all, it is entirely possible for a
binary file (especially a very small one) to have no byte values higher than
127 (0x7F), in which case it would be treated as a text file, and corrupted
by the conversion process. (You could open such a binary file in a text
editor and you'd see normal characters, though they wouldn't spell anything
intelligible). Second, not all text files are in simple 7-bit ascii English.
some use code page characters which occupy values higher than 127. In this
case the opposite would happen -- the text file would be treated as binary,
and left untouched.  Finally, the time consumed by having to scan a file's
contents before sending would make this approach unfeasible, even without
considering the above.

In summary, Samba doesn't do behind-the-scenes text file translation because
it can't. There is no 100% reliable, high-performance way to look at a file
and identify it as either text or binary.

BTW -- I've definitely had the experience of FTPing a large file and finding
it corrupted, because I'd sent it as ascii instead of binary.



  --eeyore



> -----Original Message-----
> From: samba-admin at us5.samba.org [mailto:samba-admin at us5.samba.org]On
> Behalf Of Medi Montaseri
> Sent: Tuesday, January 23, 2001 1:32 PM
> To: Thomas Langås
> Cc: samba at us5.samba.org
> Subject: Re: "\r\n" vs "\n" between Unix and Win
>
>
>
>
>
> -------------------------------------------------------------------------
> Medi Montaseri                               medi at CyberShell.com
> Unix Distributed Systems Engineer            HTTP://www.CyberShell.com
> CyberShell Engineering
> -------------------------------------------------------------------------
>
> On Tue, 23 Jan 2001, [iso-8859-1] Thomas Langås wrote:
>
> > Medi Montaseri:
> > > My user creates a text (flat file) on his windows box via Notepad.
> > > Naturally there is "\r\n" at then end of each line. User then
> > > moves this file to a Unix box (via Drive Mapping, drag-and-drop).
> > > User then logins to the unix box via telnet and run the text file
> > > which is a script.
> >
> > I would say that the best way to do this, was to use textpad or another
> > editor for windows which actually saves files with \n, instead
> of \r\n (you
>
> But DOS/Window file system demands for such "\r\n" and the application
> (ie Notepad) is simply following that. Of course an application can always
> alter things, but that becomes a local fix and not an underlying solution.
>
> > can choose UNIX-style or Windows-style). It's never a good
> solution to apply
> > a "fix" to a file just because another program doesn't behave like it
> > should. The best solution is always to fix the problem where
> it's at, ie.
> > what's causing the problem.
> >
> The problem is not the application, but the File System. And SMB is at a
> File System level, hence it should make it transparent. FTP does.
>
> But, I appreciate your input and will look into changing the process
> at creation time.
>
> > --
> > -Thomas
> >
>
>