Subject: [netatalk-admins] afpd problems (crlf & drop boxes)

From: Duncan Sinclair <[email-masked]>
Date: Wed, 11 Aug 1999 15:50:19 +0100

Hi Folks,

I've got a couple of problems I wonder are common...

1)  Drop boxes don't work.

There was discussion on this before - did it get resolved?

Basically the problem is that if directory "Drop" is a dropbox, then
afpd gives it mode "drwx-wl-w-", where the "l" means setgid, but not
group executable.  It also creates gives "Drop/.AppleDouble" the same
mode.  When someone else comes along to drop a file afpd does not have
permission to write into "Drop/.AppleDouble" due to the mode of "Drop".

I wonder if afpd can't give "x" permissions to directories without
breaking things.

2) CR <-> LF conversion is screwy.

I've talked to Adrian about this and he doesn't see it, I wonder if anyone
else (esp. Solaris or gcc 2.95 users).

I've got "options:crlf" turned on.

When I copy a text file onto my server there is no crlf processing
taking place, but it happens at all other times.

This leads to corrupt files.

e.g.
  1) Using "Simple Text", I create a local text file full of CRs.
  2) I copy it onto server - it appears on server's disk full of CRs. (wrong!)
  3) I open the server file with "Simple Text" - full of LFs. (wrong!)
  4) I edit LFs into CRs manually and re-save it on server.
  5) It now appears on the server full on LFs. (right!)
  6) Re-opening it with "Simple Text" shows the CRs. (right!)

I don't want to have to re-edit every file I copy on to my server.

Thanks for any info on these topics!

Duncan.

---

From: Clemens Anhuth <[email-masked]>
Date: Thu, 12 Aug 1999 07:04:06 +0200

>   6) Re-opening it with "Simple Text" shows the CRs. (right!)

hm...using the (updated) suse linux 6.1 package named
netatalk-1.4b2+asun2.1.3-7.i386.rpm we got some weird behavior in
this region too, but i couldn't really figure it out nor had the
time to. besides there is always the possibility that suse somehow
messed up with compiling it i guess.

here is what we got:

my usual test for wether crlf translation is active or not consists
of copying a jpg file (without resource fork, which ensures that nt
sets the mac-filetype to TEXT, as far as i understand and could
verify) from a windows nt mac-volume via a macintosh to a netatalk
volume, then load that image with a browser and see wether it got
scrambled up or not.

using the configuration files i could correctly enable and disable
crlf translation on a per volume basis.

but then one of our programmers tried to work with metrowerks
codewarrior, checking out files from another server and storing them
on the netatalk-volume. the software in this case verifies any file
written, and this is where things blew up, by having metrowerks
complain that the file just written to the netatalk volume and the
file checked out from the other server not to match anymore.

this happened regardless of wether crlf translation was switched on
or off.

i then switched back to the netatalk version shipped with suse 6.1
to have things up and running again, and plan to get back to
attempting to recompile netatalk myself some later time, whenever
time permits, then completely disabling crlf translation whereever
it can be done.

<shrug>