Subject: Re: Mapping permissions
From: Marc J. Miller (itlm019@mailbox.ucdavis.edu)
Date: Tue Dec 12 2000 - 09:59:23 EST
Well, I admit that it's a work in progress, but it is functional as-is with
a few exceptions (dropping folders into a dropbox and the Network Trash
folder, for example)... the important thing to remember here is that MacOS
has no concept of file permissions. It only understands directory
permissions. So if you want to be able to replace the file, the directory
and the .AppleDouble subdirectory must have write permissions enabled. For
best results (since it seems netatalk must be able to get into the
directory and check whether you are attempting to overwrite a file), also
enable the execute bit. Locking is a slightly different concept from
read-only. As you've already noted, MacOS stores the lock flag in the
.AppleDouble/file and that has no bearing on the permissions of the
file. I think the lock is MacOS's way of placing a restriction on a file
without restricting the whole directory. Here again, MacOS doesn't
understand file permissions. Since it's part of the resource fork
(.AppleDouble), manipulating it by changing the file permissions is easier
said than done. ...and stopping the resource fork read to check a file
permission for the lock bit, then continuing the read is likely to make
afpd run much slower.
At 11:07 AM 12/12/00 +0000, Peter Westlake wrote:
>I've just started using Netatalk, and I'm having trouble with file
>permissions. The list archives indicate that this is a feature that
>simply hasn't been implemented yet. The problem is: I have a file
>on Unix that is marked read-only. I want to replace it with a file
>from a Mac, but I can't make it writable. Locking or unlocking it
>has no effect. The lock bit gets recorded in the .AppleDouble/file,
>but that's all. The Unix permissions aren't affected.
>
>How difficult would it be to implement this? There are rather a lot
>of files in the source, so pointers to the relevant code would be
>very much appreciated. Likewise some hints as to how I might go about
>doing this. Of course, if someone has done this already, that would
>be even better!
>
>Peter.
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:46 EST