Subject: Re: Mapping permissions

From: "Marc J. Miller" <[email-masked]>
Date: Tue, 12 Dec 2000 06:59:23 -0800

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.

---

From: Peter Westlake <[email-masked]>
Date: Tue, 12 Dec 2000 16:35:20 +0000

At 06:59 2000-12-12 -0800, Marc J. Miller wrote:
>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 

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.

---

From: Peter Westlake <[email-masked]>
Date: Thu, 14 Dec 2000 18:09:42 +0000

Reminder: my problem was that I got oserror -50 when trying to delete
a read-only file from the Mac. The following changes make it work:

diff etc/afpd/file.c ~peterg/installs/netatalk-1.4b2/etc/afpd/file.c
671c671
<     if ( ad_open( file, adflags, O_RDONLY, 0, &ad ) < 0 ) {
---
>     if ( ad_open( file, adflags, O_RDWR, 0, &ad ) < 0 ) {
675c675
<           if ( ad_open( file, adflags, O_RDONLY, 0, &ad ) < 0 ) {
---
>           if ( ad_open( file, adflags, O_RDWR, 0, &ad ) < 0 ) {

diff libatalk/adouble/ad_open.c  ~peterg/installs/netatalk-1.4b2/libatalk/adouble/ad_open.c
156c156
<       admode = ad_mode( ad_p, mode==O_RDONLY? O_RDWR: mode );
---
>       admode = ad_mode( ad_p, mode );

This is in 1.4b2, no asun mods or anything like that, just
a few hacked include paths to make it compile on RedHat 6.0.

The change to ad_open.c is purely to comply with the comment
at the head of ad_open() about not opening the header file
read-only. I have no idea what goes wrong if you do, but it
didn't seem like a good time to find out. I'd be interested
to know, but only for my own interest.

This *does* seem to work, but I've only been using it for about
ten minutes. Can anyone foresee any bad side-effects of these changes?

Peter.