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

[Christopher Robison]

This could be a partial solution ... it's workable, but not very complete.
In the original author's situation, he's writing scripts, which may not have
any extension.  And declaring a share as "text files only" could be
potentially catastrophic if used by someone who didn't know that every
binary file sent there would be corrupted.

Basically, when you're creating something as fundamental as file-sharing
software or anything that works as a part of your OS's filesystem, you've
got to be paranoid. I don't think it will be soon when the authors of Samba
choose to include a feature that could potentially corrupt data. The idea of
having a feature that would change the contents of a file at all is
something they'd probably be wary of.

Maybe a solution like yours could work though, as a special-case
"you-better-know-what-you're-doing" feature.

  --eeyore


> -----Original Message-----
> From: Matt Neimeyer [mailto:neimeyer at youth-guard.org]
> Sent: Tuesday, January 23, 2001 2:27 PM
> To: eeyore at earthdome.com
> Subject: RE: "\r\n" vs "\n" between Unix and Win
>
>
>
> >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.
>
> I know that this is a huge moral, ethical, philosophical debate....
>
> Here's my question... How hard would it be to have a table, file,
> something
> that Samba looked at for file extensions to determine if the translation
> occurred...
>
> For example, if the file is a HTM, HTML, TXT, or Etc then convert it. But
> otherwise leave it be.
>
> This way the administrator could decide which files or none to
> have converted.
>
> Perhaps even on a share by share basis...
>
> Matt
>
>