Subject: Re: CRLF fun stuff again...
From: Duncan Sinclair (sinclair@dis.strath.ac.uk)
Date: Sat Feb 10 2001 - 11:03:35 EST
Paul Schinder writes:
>I missed this before.
...
>The transformations you're using aren't the ones that netatalk does
>(or at least netatalk did in the past before I turned it off). These
>are reversible. netatalk does
>
>tr '\r' '\n' to Unix and tr '\n' '\r' to Mac OS.
>
>That's why people are warning about data corruption.
Guess what? You're wrong. If people are going to try to tell me I'm
wrong, please do the research first!
Here's a chunk of code from afpd's fork.c file. It uses an identical
process for reading and writing files...
/*
* If this file is of type TEXT, swap \015 to \012.
*/
if (xlate) {
for ( p = rbuf, q = p + rbuflen; p < q; p++ ) {
if ( *p == '\015' ) {
*p = '\012';
} else if ( *p == '\012' ) {
*p = '\015';
}
}
}
I hope you can all see what this code is doing. In case you can't
I'll spell it out....
It goes through the buffer of data to be written or having been read,
if it finds a return ('\015') it turns it into a linefeed ('\012'),
otherwise if it finds a linefeed it turns it into a return. The exact
same thing for both reading and writing. It can only do this if the
transformation is symmetric.
Frankly I'm surprised at the number of people who are confused on this
matter. I'm not a newbie to netatalk. I've been using it since around
version 1.3.3. I actually know what I'm talking about here.
So, once more I'll repeat it. The netatalk cr/lf code worked very
well until MacOS 8 came out. Then the way the Finder copies file
causes it not to work correctly. It'd be nice if this could be fixed.
If you don't like the code, fine - it is off by default. Please stop
trying to tell me I don't want the feature at all. I really, really,
really do.
Later today or tomorrow I'll post a slightly revised method of making
this stuff work. I'll be happy to receive constructive criticism on
that.
Cheers,
Duncan.
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT