Subject: Re: [netatalk-admins] Can't stop CR/LF translation...
From: bsmith@h-e.com
Date: Tue Mar 24 1998 - 21:57:05 EST
Original message sent on Tue, Mar 24 10:12 AM by davidw@gate.cks.com (David
Welton) :
> I first noticed this when I used the server I have set up to transfer
> some gif's from my boss. He created them on his windoze box, then
> placed them in a shared directory hosted by a Mac appletalk server.
> From there I moved them to my own netatalk server, clicking and
> dragging with a mac... At this point I went to open an image, and, lo
> and behold, corruption!
>
> ...So I went to change AppleVolumes.system in /etc/netatalk, and I
> restarted the server (first I tried hupping it twice, to no effect),
> after having edited it to the following:
>
> . BINA UNIX
> # . TEXT UNIX
The AppleVolumes.system mappings apply only to files that do not already have a
type and creator (i.e. files created from the Unix side). Any file copied to a
netatalk volume from the Mac will already have a type and creator, and the
AppleVolumes.system mappings will not "override" those. In your case it sounds
like the file types were set to "TEXT" when the files were copied from the
Windows machine, so the file types will remain "TEXT" no matter what you do to
the AppleVolumes.system file and netatalk will continue to translate the files.
There are two possible solutions, one would be to prevent the files from being
typed as "TEXT" to start with. This would depend on the software being used to
copy the files from the Windows machine to the AppleShare server; that is where
the file type is being defined in this case.
The other solution is to completely disable netatalk's CR/LF translation, which
is simply a matter of re-compiling netatalk after removing the "-DCRLF" option
from etc/afpd/Makefile.
Hope this helps!
Bob Smith
Hammett & Edison, Inc.
bsmith@h-e.com
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:31:55 EST