[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: one-way cr/lf translation
From:       Peter DiCamillo <Peter_DiCamillo () brown ! edu>
Date:       2000-01-27 22:04:40
[Download RAW message or body]

Duncan Sinclair wrote:
>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.
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

[prev in list] [next in list] [prev in thread] [next in thread]