Subject: CRLF fun stuff again...

From: Jeremy Buchmann <[email-masked]>
Date: Thu, 01 Feb 2001 15:33:32 -0800

Hello,
    I have just installed netatalk 1.4b2 and cannot get it to do the
CRLF->LF translation when copying files from a Mac to my Linux machine.  I
didn't make any changes to the makefile other than specifying the DESTDIR.
Here is my AppleVolumes.default:
/somewhere/import "Import" options=crlf,noadouble

and here is my AppleVolumes.system:
.txt TEXT UNIX
.txt TEXT FOXX
.    TEXT UNIX

(I have tried all sorts of variations of the above lines, none work)
And here is my afpd.conf:
"Import" -nouservol

The files I copy over are text files with the .txt extension generated by
Visual FoxPro (FOXX).  Any ideas?

--Jeremy

---

From: Duncan Sinclair <[email-masked]>
Date: Fri, 02 Feb 2001 13:23:42 +0000

Hi,

Jeremy writes:
>CRLF->LF translation when copying files from a Mac to my Linux machine.

> ...

>Visual FoxPro (FOXX).  Any ideas?

This is (as far as I'm concerned) the single biggest bug in netatalk.

The problem is that the cr/lf translation only happens when netatalk
sees that the file is text before it is written.  Unfortunately, since
MacOS 8, the Finder doesn't set the file type to TEXT until after the
copy is finished.  Thus no cr/lf conversion.

The only way to make this work properly is to re-process files when
their type is changed to "TEXT".  There are, of course, big gotchas
over this, like the Mac might expect a simple attribute change to
happen in an instant, rather than having to wait for as long as it
takes to re-write the text file.

Here's my proposed solution:
  * A second "helper" process would run along side the main afpd process,
    tied to it with pipes.
  * tasks would be handed to it like "do a cr/lf translation of this file".
  * it would have to take care to lock files.
  * tasks are done serially - to make sure nothing gets screwed.
  * there may be other types of thing it could be used for.

This would not be a trivial amount of code.

Every time I have had a few spare hours to look at this I'm been scared
away by the complexity of the afpd code.  I don't think I'll have
sufficient time to actually write any code to do this in the forseeable
future.

Until now, every time I mention this problem, people tell me that I
shouldn't want to do cr/lf translation, and it's an ugly hack.  My reply
is that it is necessary for cross platform file manipulation, and I
really, actually, want it, thank you very much.

I now hope that someone will email me back saying that this is fixed in
the latest beta version.  (please!)

Cheers,

Duncan.

---

From: Donald Lee <[email-masked]>
Date: Sat, 3 Feb 2001 00:16:26 -0600

At 7:23 AM -0600 2/2/01, Duncan Sinclair wrote:
> etc...

There has been a lot of discussion of the CR/LF translations on this list.

If I may add my two cents, I think it's a bad idea for the filesystem to
effectively blindly fondle and convert the data.  There are plenty of tools
out there, like bbedit, that handle text files regardless of how their
line endings are done.

The downside of a problem with the CR/LF "feature" is irretrievably corrupted
data.  What you get for this is arguably a minor "convenience".

I think it's a bad trade.

I keep it turned off, and recommend this to all who ask.

-dgl-

---

From: Jeremy Buchmann <[email-masked]>
Date: Mon, 05 Feb 2001 09:27:57 -0800

> I think it's a bad trade.

Not for me.  Here, we would only be copying text files, so I would like the
option to blindly convert all files whether netatalk thinks they are text or
not.  After all, who knows better, netatalk or me?  If we can't blindly
convert, we'll just have to stick to fetch.  Oh well.

--Jeremy