About
What does it do for me?
It prevents creation of .DS_Store files. It redirects their creation into a special folder.
Why is .DS_Store a problem?
Well, it is not really a problem for most Mac users because .DS_Store files are normally hidden in the Finder.
But I'm a developer and I run Finder with TotalFinder and I have enabled display of hidden files. Also I run a lot of command-line tools via terminal. The problem is that sometimes .DS_Store files get into a way. I hate when my clean new folders get polluted by those small tiny files holding unimportant garbage. I hate when I zip a folder using some unix command and it includes .DS_Store files in the archive. I hate when I visit a network volume and that pollutes its content with those nasty files. To put it simply I don't want my geeky Windows friends to laugh at me because this makes me look incompetent.
That is why I decided to solve this for myself and I'm sharing my solution with other Mac geeks out there to help them protect their egos :-)
Asepsis does .DS_Store redirection. How does it work technically?
Apple implemented a private system framework DesktopServicesPriv which is responsible for creating and manipulating .DS_Store files. This framework is used mainly by Finder, but there are also other system apps which link against it and may use it (yes mdworker I'm looking at you!). DesktopServicesPriv uses standard libc calls to manipulate .DS_Store files.
At core Asepsis provides a dynamic library DesktopServicesPrivWrapper which gets loaded into every process linking against DesktopServicesPriv.framework. It interposes some libc calls used by DesktopServicesPriv to access .DS_Store files. Interposed functions detect paths talking about .DS_Store files and redirect them into a special prefix folder. This seems to be transparent to DesktopServicesPriv.
Additionally Asepsis implements a system-wide daemon asepsisd whose purpose is to monitor system-wide folder renames (or deletes) and mirror those operations in the prefix folder. This is probably the best we can do. This way you don't lose your settings after renaming folders because rename is also executed on a folder structure in the prefix directory.
The prefix folder is /usr/local/.dscage
DesktopServicesPrivWrapper- a proxy library for interposing file manipulation calls in DesktopServicesPrivasepsisd- a system-wide daemon for mirroring folder renames and deletes in the prefix folderasepsisctl- a command-line utility for controlling Asepsis operation
Installation
To install the software:
- Run the installer
- Restart your computer
After reboot .DS_Store files are no longer created when you open Finder and browse folders (in case .DS_Store files are not already present there).
Troubleshooting
In Terminal.app run:
asepsisctl diagnose
Updates
Asepsis checks for update after every reboot using Sparkle framework. It also checks its consistencty at that point.
Uninstallation
Just run provided uninstaller from the DMG archive or in Terminal execute:
asepsisctl uninstall
sudo reboot
Alternatively you may use uinstaller which comes with the DMG archive. It launches asepsisctl uninstall for you.
Installing from sources
You may want to review the source code and install it by compiling it from sources. Please follow instructions in GitHub repository.
Control
You may control asepsis operation via asepsisctl
During the installation asepsisctl tool is symlinked into /usr/local/bin, so it should be visible from the command-line.
> asepsisctl --help
The control script for asepsis operations.
Usage:
asepsisctl [command] [options]
Commands:
disable Disables asepsis.
enable Enables asepsis.
diagnose Diagnoses asepsis setup.
Helper commands:
neton Enables DS_Store files on network volumes.
netoff Disables ... (http://support.apple.com/kb/ht1629).
migratein Migrates .DS_Store files in /usr/local/.dscage.
migrateout Migrates .DS_Store files from /usr/local/.dscage.
prune Removes empty directories from /usr/local/.dscage.
clean Deletes all content from /usr/local/.dscage.
Installation commands:
install Performs reinstallation (using "/Users/darwin/code/asepsis/bin/Asepsis").
uninstall Performs complete uninstallation.
install_wrapper Installs DesktopServicesPriv.framework wrapper.
uninstall_wrapper Uninstalls DesktopServicesPriv.framework wrapper.
remove_symlink Removes asepsisctl symlink from /usr/local/bin.
create_symlink Creates asepsisctl symlink in /usr/local/bin.
make_dscage Makes sure /usr/local/.dscage exists with sufficient rights.
kill_daemon Stops asepsis daemon.
uninstall_daemon Uninstalls asepsis daemon.
install_daemon Installs asepsis daemon.
launch_daemon Launches asepsis daemon.
enable_warnings Enables warnings caused by mach_override (vm.shared_region_unnest_logging)
disable_warnings Disables warnings caused by mach_override (vm.shared_region_unnest_logging)
uninstall_updater Uninstalls asepsis updater.
install_updater Installs asepsis updater.
Backward compatibility:
uninstall_dylib Removes libAsepsis.dylib from /etc/launchd.conf.
uninstall_kext Removes /System/Library/Asepsis.kext during next boot.
Where options are:
-r, --root /Users/darwin Root folder for migration
-d, --[no-]dry Run migration in dry mode
-v, --[no-]verbose Be more verbose
-f, --[no-]force Force operation
-h, --help Show this message
-V, --version Print version
Diagnose
Asepsis modifies system files in /System/Library/PrivateFrameworks/DesktopServicesPriv.framework.
As you can guess there is a clear risk that during system update Apple reverts files to the originals. This should be no big deal. Asepsis checks for this at every reboot and reports it. Reinstalling asepsis should patch it back. In the worst case you will notice that you have .DS_Store files creeping back in the house.
To diagnose asepsis run:
asepsisctl diagnose
Here is the script source: https://github.com/binaryage/asepsis/blob/master/ctl/cmd/diagnose.rb
To reinstall DesktopServicesPriv wrapper run:
asepsisctl uninstall_wrapper
asepsisctl install_wrapper
Here is the script source: https://github.com/binaryage/asepsis/blob/master/ctl/cmd/install_wrapper.rb
The list of known issues
General
- when copying folders, DS_Store settings are not copied over (daemon is unable to distinguish this class of file operations)
Please report any issues.
FAQ
Sounds scary. Is this safe?
Well uhmmm, use it at your own risk :-) It sounds scary but it should be a pretty lightweight solution. You should review the code to see what it does.
Could this be ported to Snow Leopard?
Probably yes. Pre-Lion DesktopServicesPriv calls File Manager APIs from CoreServices. Technically the same approach could be done to File Manager. Actually this is what TotalFinder (prior to version 1.3) did under Snow Leopard using mach_override. I'm not going to implement it for Snow Leopard because I've already switched to Lion personally.
What if .DS_Store file is already present in a folder?
Asepsis will use it. It won't redirect it in this case. This way Asepsis works seamlessly with DMG archives or folders you browse on a network. If you delete the .DS_Store file, next time it will be created in the prefix folder. This is pretty simple approach how to adopt Asepsis incrementally on folder-by-folder basis.
How could I migrate existing .DS_Store files?
Please see
asepsisctl migrateincommand
Are there any processes which don't work well with Asepsis?
Asepsis has white-list of processes known to manipulate with .DS_Store files. Right now it is effective for Finder.app and mdwrite process.
What about using resource forks for hiding .DS_Store files?
Nice idea! This would be probably a more elegant approach but it would work only for HFS+ volumes. I haven't tried to implement it via resource forks. I decided to run with this prefix-folder approach which seemed to me as a more predictable approach. Feel free to fork and experiment.
How can I keep Asepsis up-to-date?
Asepsis is using Sparkle updater. You should be prompted when a new version comes out. Asepsis checks for new version after every reboot.
What happened in 10.7.4 update?
Previously Asepsis used DYLD_INSERT_LIBRARIES to modify DesktopServicesPriv during load time. Unfortunately Flashback malware used the same mechanism and Apple decided to block system-wide usage of DYLD_INSERT_LIBRARIES in 10.7.4 update. As a workaround Asepsis 1.2 modifies DesktopServicesPriv on the disk during installation. This is more dirty solution. At least I have implemented post-login check which will inform you that someone reverted Asepsis changes back. For example after you do a system update and Apple may rewrite DesktopServicesPriv framework with new version. In this case
asepsisctl install_wrappershould patch it again but better wait for my update.
Does Asepsis install some kernel extension?
Since version 1.3 Asepsis does not use kernel extension anymore.
