Just 2 cents.
.DS_Store files can get axed. They are sort of akin to windows thumb.db files.
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
pre-X and OS X application framework.) are being phased out in favor
of Cocoa (OS X only applications), it really isn't too far of a
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
these files for you.
I can understand where large sites don't want to go this route
globally since it could break something. As I am positive someone is
still using OS 8 around here for that 1 application and most
definitely there are carbon applications still abound.
I can understand where AFS Team doesn't want to make it a global
default option.
I can understand where a user would want the ability to just not
create the files by default if they are accessing shared space from
multiple platforms, or especially if space is limited, ie someone
charges for space.
I can understand where an administrator in an office environment would
want to disable this right at the server too. IE you can control, your
environment, but say someone installs the afs-client on their mac at
home, and accesses the space without running say a disable creation
flag, and now you have litter all over the place.
There could be a flag that disables the creation of the .x files on
the MacOS X client as well as the thumb.db files on the windows
client. But to do it thoroughly, I would suggest having a way to
disable both altogether server side as client side.
It would actually be kind of cool to be able to control this on say a
volume by volume basis for say groups of windows or mac users where
they could utilize the extra speed and not have to go through and
"pretend" recreate of the cache type of files every access.
Im not sure how well this would work, but instead of creating thumb.db
files, and .DS_Store files in the global afs filesystem space, they
could be forked, and just stored locally in the cachemanager cache or
a temp file on the local system. In otherwords, the .DS/thumb.db files
never make it to the fileserver, they are simply stored in a special
the client cache file instead.
Quoting Derrick Brashear <[email protected]>:
On Sun, Oct 10, 2010 at 3:24 PM, Adam Megacz <[email protected]> wrote:
MacOS seems to litter network shares with two kinds of files:
.DS_Store (Finder data)
._filename (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? The 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. This has the advantage of not
being filename-based and not breaking programs which access the
filesystem through the POSIX APIs.
- a
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Derrick
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
