Subject: Re: Mapping permissions
From: Peter Westlake (peter@harlequin.co.uk)
Date: Tue Dec 12 2000 - 11:35:20 EST
At 06:59 2000-12-12 -0800, Marc J. Miller wrote:
>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.
Now that's an interesting point. Unix can delete a file even if
it isn't writable, as I should have remembered at once. So it
ought to work if I delete the file first and then copy over the
new one. However, my programs already try to do that, and that's
when I get error -50, parameter error. Trying it from the Finder,
I *can* move the file to the Trash, and it gets moved to the
Network Trash Folder on the server. It's only when I try to
empty the Trash that it gives the error. In other words, when
actually deleting the file, just as when the programs do it.
>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.
I see, I think. Locking is probably irrelevant to me in this case
- it was just something I thought might affect the permissions.
It now sounds as though I don't need to worry about permissions
much, although they evidently have *some* bearing on whether or
not a file can be deleted. What should I try now, I wonder?
Thanks,
Peter.
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:46 EST