[OpenAFS] MacOS AppleDouble excretions

[omalleys@msu.edu]

Just 2 cents.

.DS_Store files can get axed. They are sort of akin to windows thumb.db fil=
es.

Resource forks:
This guy said it better than I could:
http://jonsview.com/mac-os-x-resource-forks

For OS pre-X and I -think- carbon applications, they need to be there.

Given OS pre-X applications, were phased out, and carbon (both os =20
pre-X and OS X application framework.) are being phased out in favor =20
of Cocoa (OS X only applications), it really isn't too far of a =20
stretch to make available a way to phase it out the resource forks.

There is an Application on the Mac called BlueHarvest that does delete =20
these files for you.

I can understand where large sites don't want to go this route =20
globally since it could break something. As I am positive someone is =20
still using OS 8 around here for that 1 application and most =20
definitely there are carbon applications still abound.

I can understand where AFS Team doesn't want to make it a global =20
default option.

I can understand where a user would want the ability to just not =20
create the files by default if they are accessing shared space from =20
multiple platforms, or especially if space is limited, ie someone =20
charges for space.

I can understand where an administrator in an office environment would =20
want to disable this right at the server too. IE you can control, your =20
environment, but say someone installs the afs-client on their mac at =20
home, and accesses the space without running say a disable creation =20
flag, and now you have litter all over the place.

There could be a flag that disables the creation of the .x files on =20
the MacOS X client as well as the thumb.db files on the windows =20
client. But to do it thoroughly, I would suggest having a way to =20
disable both altogether server side as client side.

It would actually be kind of cool to be able to control this on say a =20
volume by volume basis for say groups of windows or mac users where =20
they could utilize the extra speed and not have to go through and =20
"pretend" recreate of the cache type of files every access.

Im not sure how well this would work, but instead of creating thumb.db =20
files, and .DS_Store files in the global afs filesystem space, they =20
could be forked, and just stored locally in the cachemanager cache or =20
a temp file on the local system. In otherwords, the .DS/thumb.db files =20
never make it to the fileserver, they are simply stored in a special =20
the client cache file instead.


Quoting Derrick Brashear <shadow@gmail.com>:

> On Sun, Oct 10, 2010 at 3:24 PM, Adam Megacz <adam@megacz.com> wrote:
>>
>> MacOS seems to litter network shares with two kinds of files:
>>
>> =A0 .DS_Store =A0 (Finder data)
>> =A0 ._filename =A0(AppleDouble resource fork)
>>
>> There's a MacOS setting to disable the first kind of litter.
>>
>> 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.
>
> Since you suggest your first comments are what we misinterpret: if
> Apple thinks turning this off is a bad idea, why is it you think we
> should think they're wrong?
>
>>
>> Is there any chance of a setting being included in the MacOS client that
>> stops this from happening? =A0The crude way would be to simply refuse to
>> create files whose name starts with the prefix "._", reporting
>> permission-denied or something like that.
>>
>> 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. =A0This has the advantage of n=
ot
>> being filename-based and not breaking programs which access the
>> filesystem through the POSIX APIs.
>>
>> =A0- a
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>
>
>
> --
> Derrick
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>