Hi! I’m experimenting with Asepsis in a shared storage environment. I have about 15 machines all connected to an Xsan. As you probably know .DS_Stores are a real problem on shared storage. They cause frequent problems where machines are fighting to read/write to them when a lot of people are working out of the same project folders, which is usually the case in my environment. I constantly have them getting corrupted, or have the metadata controller sitting there scratching it’s head while my users navigate to a folder and all they see is the spinning wheel in the status bar of the window - the contents never display. If I open a Terminal session and delete the DS_Store file in that directory, the contents display on all machines instantaneously. It’s really driving me nuts. The only thing I can seem to do is to forbid all my users from working in Column mode or using the twirl-down arrows when navigating the filesystem… but that pretty ludicrous. They should be able to use their machines how they like without screwing up anyone else. The com.apple.desktopservices DontWriteNetworkStores true command works only for SMB/AFP/NFS shares. Not Xsan… which has exactly the same problems that plague network shares… But the option doesnt work for Xsan. So Asepsis would seem to be an ideal solution! You get the benefits of what the .DS_Store files give, but they are specific to your machine.
So I’ve run into a few issues. This seems to work great for the most part. However there are a few issues.
-
Asepsis requires the Xcode command line utilities to run. This is a little bit of a pain for a workgroup situation because the command line tools have to be installed on every machine in the SAN environment. I found the easiest way to do this is to use Apple Remote Desktop and use Copy to distribute /Library/Developer to all the machines. This eliminates the need to interact with each machine individually.
-
Other applications (other than Finder) still write DS_Store files to the SAN. For example, any time someone opens an Open/Save dialog in any application, they have the opportunity to create a DS_Store file in any directory on the SAN if they use the folder twirl-downs, switch to column mode, etc.
-
It would be great if Asepsis had the option to ignore DS_Stores present and always use the priv folder. That would at least solve the problem of machines trying to read open files.
-
The DS_Stores files created in the priv folder are owned by the user who created them, group is wheel, and permissions are set to 644 (Owner read/write, group read, everyone read). This is great for a single-user environment where only one user is logging into a particular machine. However in my environment I have multiple users logging into many different machines. Our machines are all bound to Active/Open Directory services. With the permissions on the priv DS_Stores set this way, if someone else logs into that machine, they do not have the permission to make changes to the DS_Store files in the priv folder, only read them. So the priv folder becomes riddled with permissions issues.
So those are my observations. Based on the history of Asepsis that I read, it seems like you were more thinking in terms of keeping your own personal filesystem clean in your development environment. But it really does work well in an Xsan environment and could be even better if some of these things were addressed!