[OpenAFS] MacOS AppleDouble excretions

omalleys@msu.edu omalleys@msu.edu
Fri, 15 Oct 2010 14:45:56 -0400


Quoting Derrick Brashear <shadow@gmail.com>:


> POSIX extended attributes are stored in the files. Until we deal with
> them natively (which requires new RPCs) deleting them actively loses
> data.
> If you store them locally, you're not saving all the data.
>
> They are not solely used to store OSX-specific data.

That is good to know. :)

I would go as far as split the Attribute files ie desktop.ini and the  
.AppleDouble from the list of locally cached files since they are not  
local cache files.

The thumb.db and the .DS_Store data sounds like they should be stored locally.

Imagine say 40 windows clients connected to a RO volume that last had  
a bunch of files last put in by a unix client before being released.  
The cache databases would be out of sync causing a reload of the data  
at every access.
Or even better someone decides to "clean" afs by deleting all these files.
(because they are getting charged for space.)

Every afs client would have to support local caching of "windowing"  
cache files. You could for instance have a samba/afs or samba/netatalk  
gateway where the unix afs client is actually doing the writing the  
thumb.db or .DS_Store files. Thus it isn't just a platform specific  
issue.

Also, my guess is both Gnome, KDE and other windowing systems have a  
similar cache type of files as well and will have similar files that  
should be cached locally as well.

Is this a pretty safe assumption?

Now what happens to the Attribute files desktop.ini or the  
.AppleDouble file if you add say 1000 files from a unix client to the  
directory? how are the extended attributes dealt with if the extended  
attribute file, is older then the files and a new one cannot be  
written? im just curious.

> So, if you want to throw away data, I can suggest other optimizations.
> Things will be very, very fast.

I have no doubts. :)