[OpenAFS] MacOS AppleDouble excretions

[Steve Simmons]

On Oct 10, 2010, at 3:24 PM, Adam Megacz wrote:

> MacOS seems to litter network shares with two kinds of files:
>=20
>   .DS_Store   (Finder data)
>   ._filename  (AppleDouble resource fork)
>=20
> There's a MacOS setting to disable the first kind of litter.
>=20
> Unfortunately it seems like there is no way to get MacOS to refrain =
from
> writing the second kind of file, and it seems like Apple deliberately
> doesn't want there to be one.

There is other 'cruft' as well, eg, Icon* files.

I don't know that I'd characterize it that way (ie, Apple deliberately =
doesn't want...). OSX requires resource forks and a few other things in =
order for some significant and important application stuff to work =
correctly. hfs can make those forks completely invisible. afs can't (or =
at least, doesn't). So Apples choices were to either not have files work =
correctly when stored on non-Apple file servers, or find some =
workaround. They chose a workaround, and their choice greatly helps us =
in making afs useful for Mac users.

There is a third alternative, wherein they could have put resource forks =
into oAFS. And CIFS. And SAMBA. And NFS. And zfs. And filesystem du =
jour, etc. They chose instead to do it in a largely =
filesystem-independant way, and the results are pretty consistent and =
thorough across file services. It's hard to argue with their success.

> Is there any chance of a setting being included in the MacOS client =
that
> stops this from happening?  The crude way would be to simply refuse to
> create files whose name starts with the prefix "._", reporting
> permission-denied or something like that.

Doing this at our site would result in a firestorm of complaints from =
our Mac users when their resource forks on afs-based files start =
failing. See below also.

> The more sophisticated approach would probably be to claim to MacOS =
that
> /afs/ supports resource forks, and report permission-denied when an
> attempt to write a resource fork is made.  This has the advantage of =
not
> being filename-based and not breaking programs which access the
> filesystem through the POSIX APIs.

I may have missed a step here. My admittedly weak understanding of how =
resource forks work is that the ._filename files are only created when =
the underlying filesystem doesn't support resource forks. It sounds like =
you're suggesting we modify afs so it understands resource forks =
properly and generate an error message if someone attempts to create a =
file whose name might be mistaken for a resource fork.

But if I understand things correctly, OSX would then put the forks in =
directly, presumably in some manner rather like an acl. The issue of =
creating ._filename fork files simply wouldn't come up. Thus there would =
be no need to forbid the creation of ._filename files; they'd simply be =
ignored *as resource forks* by OSX. Users could create those files, and =
they'd just be plain files. IMHO that's a better solution than =
mysteriously (to the user) forbidding a particular format of filename.

Even if we fix ._ resource forks by moving stuff into afs resource =
forks, it still doesn't get rid of the 'cruft' like .DS*, Icon*, etc. =
Removing those files, whether ._filename or .DS*, also removes the =
ability to copy them to other filesystems and have the OSX-ishness of =
the result be correct. At this point, the problems solved seem to be =
less of a win than the problems to be introduced by such a change.

Steve=