Subject: Re: one-way cr/lf translation

From: Duncan Sinclair <[email-masked]>
Date: Mon, 17 Jan 2000 15:10:11 +0000

Steve Hodges writes:

>I want to use CR/LF translation for text files. ...

>The strange thing is:  CR/LF translation works fine when
>I copy a file created on the linux side to a
>Mac; I can view the file with SimpleText and all the
>returns look right.  However, if I create a text file on the Mac's
>local hard drive and then copy it to the linux machine, it has ugly
>^M characters still in it when viewed from linux.

I have this problem too.

The basic cause is that the Finder does not copy files using their
correct creater/type codes, but uses its own code.  This means
that netatalk never knows to translate the file being copied.

At all other times it does the translation, but without the finder
copy translation being done, things get messed up.

The answer, to me, seems to be to post-process files if when the
finder changes their file type to "TEXT".  I suggested this change
to Adrian recently, but I could understand if he is a little
hesitent to implement this change without some thought as to
its effects.

(IIRC, when over-writing an existing text file, it seems to do the
translation, so post-processing whould be the wrong thing.)

Duncan Sinclair.

---

From: Peter DiCamillo <[email-masked]>
Date: Thu, 27 Jan 2000 17:04:40 -0500

>copy translation being done, things get messed up.
Thanks for the explanation.  I'll add to it that since the type of 
the file copied by the Finder is eventually set to TEXT, when the 
file is read by a Mac, cr/lf translation *is* done.  This behavior 
concerns me, because it means that a user cannot copy a TEXT file to 
netatalk, then copy it back, and get the same file.  In a sense, 
netatalk is corrupting TEXT files copied by the Finder (although a 
program such as BBEdit can fix them).  To me, this is much more 
serious than the issue of whether the copied files are usable in 
unix, or perhaps via samba.

Part of the problem is that the translation code, both for reading 
and for writing, swaps CR and LF characters.  One possible solution 
would be to have the writing code only translate Mac newline 
characters, and the reading code only translate unix newline 
characters.  Another possibility might be to keep a flag bit along 
with the type information, to indicate whether the TEXT file was 
actually translated when it was created.  Of course, that would cause 
a problem if the file was fixed using unix after being written.  I'm 
not sure what the best solution is, but it's important that copying 
text files to and from netatalk using the Finder doesn't modify them.

Peter