[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. :)