In Defense of the .DS_Store File
Wednesday, 2007-09-26; 15:07:00
While it's fun to hate on the Finder for it being slow, being unresponsive while accessing network shares, losing per-window settings, putting icons in random positions, grinding iDisk connections to a halt, locking everything up while generating icon previews, etc., etc., one of the most misunderstood and under-appreciated aspects of the Finder is the .DS_Store file.
The reason I bring this up is a recent announcement made by CocoaTech that their Finder-replacement will sport per-folder window settings, something that has apparently been oft-requested by users. I'll quote the same section as Gruber did in his Linked List entry about this announcement:
Gruber's entry is composed entirely of this quote with no commentary whatsoever. So while he doesn't make it explicit, his excerpting seems to imply that he thinks there's something fundamentally wrong with .DS_Store files. And CocoaTech certainly brands them as "notorious".
Here's what happens: whenever you modify your window settings in the Finder such that they only apply to the folder you're currently working in, the Finder stores these settings in an invisible (we'll qualify that in a sec) file named ".DS_Store" inside that same folder. Simply visiting a folder is sometimes enough to create one of these .DS_Store files. The Finder needs to remember what position the window for that folder was in, the type of window (Aqua or brushed metal), the size of the window, etc., and it stores it in these files. Other things that can trigger the creation of a .DS_Store file: simply changing a window's settings from "All Windows" to "This Window", moving icons around, etc.
The problem manifests itself when people on other operating systems start browsing folders in which the Finder has created these .DS_Store files, Windows in particular. Since Mac OS X is based on UNIX (and is a UNIX variant as of Leopard), all files that start with a "." are automatically rendered invisible. This is true of other UNIX-based operating systems, so they're more likely to not encounter the .DS_Store files. Windows does not have this mechanism, so when a Windows user opens a folder which a Mac user has opened in the past, he'll see a .DS_Store file.
The Finder creates these .DS_Store files even when visiting network volumes. If a Mac user is connecting to a largely Windows-dominated environment, many Windows users will probably be surprised and annoyed to see a bunch of .DS_Store files littering their previously pristine folders.
But back to CocoaTech. Their solution to the ".DS_Store litter" problem is to store all per-window settings in a single file. This is not such a hot decision, for two main reasons.
First, as pointed out by Adrian Liechti in the comments of the announcement, this is problematic when a user moves a folder around. If you create a folder, modify its per-window settings, and move it to a new location or rename it, what happens? In the Finder, that folder's per-window settings are preserved, because the settings are stored right in the folder itself. If the settings are stored in one big database file, how are things handled? How does Path Finder 4.8 ensure that a moved folder retains its settings?
I can see a few methods of doing so. The first is to use the HFS file system to keep track of folders rather than using the path to the folder. (This is how aliases continue to work even when you move the file it points to from its original location.) Folders and files can be referred to by an internal data structure, so that even when they're moved around, the file system still knows where they are. This is probably the best option, and hopefully the CocoaTech folks chose this route. Since Path Finder 4.8 hasn't been released yet, it's not clear if this is how they're doing it.
Another option is to continuously monitor file-system changes and update the database when a folder gets moved. This is much more expensive in terms of CPU usage and disk access because every time a folder is moved, Path Finder needs to be notified and its database file needs to be updated. However, with Tiger you can monitor certain portions of the file system and it will generate notifications only when something changes. Path Finder would have to do this for all connected volumes, however, which could be more effort than its worth.
The second reason, however, that .DS_Store files are better is that they're much less susceptible to corruption. If a single .DS_Store file gets damaged, all that gets lost is the per-window settings for that window. However, if the Path Finder database file gets damaged and is irreparable, all of the user's per-window settings get lost. All of them gone, kaput.
Path Finder could mitigate this problem by keeping a couple backups of the database file somewhere, but it's still much more at risk compared to the .DS_Store files. For this reason alone I think that the single-database method is not a good risk to take, at least in an all-or-nothing fashion.
I think a hybrid method would be a better solution to the problem. For internal Macintosh drives, there's no reason to eschew .DS_Store files. Windows users might see them when they connect to the Macintosh, but they shouldn't really have a problem with that because it's not their hard disk. For network drives, however, a database file (perhaps one per volume, to combat corruption) would make more sense. These would be stored in the Mac user's local home directory. .DS_Store files wouldn't be created on the network volume, and the Mac user could still retain his per-window settings for network volumes.
Incidentally, if you were wondering, you can already turn off the creation of .DS_Store files on network volumes in Mac OS X. Just in case Windows users are already all over you about your .DS_Store files.
The reason I bring this up is a recent announcement made by CocoaTech that their Finder-replacement will sport per-folder window settings, something that has apparently been oft-requested by users. I'll quote the same section as Gruber did in his Linked List entry about this announcement:
Unlike the Finder (with its notorious .DS_Store files) we use no hidden files, we do not require files scattered around in every directory, and no helper files will ever silently appear on your network shares or external hard drives.
Path Finder 4.8 will store its visual per-folder settings in a centralized SQLite database located in ~/Library/Application Support/Path Finder/CoreData. Its size is very small - mine currently weighs just about 150 KB.
Gruber's entry is composed entirely of this quote with no commentary whatsoever. So while he doesn't make it explicit, his excerpting seems to imply that he thinks there's something fundamentally wrong with .DS_Store files. And CocoaTech certainly brands them as "notorious".
Don't be fooled, just visiting a folder can create a .DS_Store file. But not in the folder itself: visiting a folder creates a .DS_Store file in the parent folder. This is true of the settings for the size, position, and type of Finder window, as well as the "All windows"/"This window" radio button setting in the View Options panel. This is a bit peculiar given the first caveat with Path Finder's method, discussed below.
Here's what happens: whenever you modify your window settings in the Finder such that they only apply to the folder you're currently working in, the Finder stores these settings in an invisible (we'll qualify that in a sec) file named ".DS_Store" inside that same folder. Simply visiting a folder is sometimes enough to create one of these .DS_Store files. The Finder needs to remember what position the window for that folder was in, the type of window (Aqua or brushed metal), the size of the window, etc., and it stores it in these files. Other things that can trigger the creation of a .DS_Store file: simply changing a window's settings from "All Windows" to "This Window", moving icons around, etc.
The problem manifests itself when people on other operating systems start browsing folders in which the Finder has created these .DS_Store files, Windows in particular. Since Mac OS X is based on UNIX (and is a UNIX variant as of Leopard), all files that start with a "." are automatically rendered invisible. This is true of other UNIX-based operating systems, so they're more likely to not encounter the .DS_Store files. Windows does not have this mechanism, so when a Windows user opens a folder which a Mac user has opened in the past, he'll see a .DS_Store file.
The Finder creates these .DS_Store files even when visiting network volumes. If a Mac user is connecting to a largely Windows-dominated environment, many Windows users will probably be surprised and annoyed to see a bunch of .DS_Store files littering their previously pristine folders.
But back to CocoaTech. Their solution to the ".DS_Store litter" problem is to store all per-window settings in a single file. This is not such a hot decision, for two main reasons.
First, as pointed out by Adrian Liechti in the comments of the announcement, this is problematic when a user moves a folder around. If you create a folder, modify its per-window settings, and move it to a new location or rename it, what happens? In the Finder, that folder's per-window settings are preserved, because the settings are stored right in the folder itself. If the settings are stored in one big database file, how are things handled? How does Path Finder 4.8 ensure that a moved folder retains its settings?
I can see a few methods of doing so. The first is to use the HFS file system to keep track of folders rather than using the path to the folder. (This is how aliases continue to work even when you move the file it points to from its original location.) Folders and files can be referred to by an internal data structure, so that even when they're moved around, the file system still knows where they are. This is probably the best option, and hopefully the CocoaTech folks chose this route. Since Path Finder 4.8 hasn't been released yet, it's not clear if this is how they're doing it.
Another option is to continuously monitor file-system changes and update the database when a folder gets moved. This is much more expensive in terms of CPU usage and disk access because every time a folder is moved, Path Finder needs to be notified and its database file needs to be updated. However, with Tiger you can monitor certain portions of the file system and it will generate notifications only when something changes. Path Finder would have to do this for all connected volumes, however, which could be more effort than its worth.
The second reason, however, that .DS_Store files are better is that they're much less susceptible to corruption. If a single .DS_Store file gets damaged, all that gets lost is the per-window settings for that window. However, if the Path Finder database file gets damaged and is irreparable, all of the user's per-window settings get lost. All of them gone, kaput.
Path Finder could mitigate this problem by keeping a couple backups of the database file somewhere, but it's still much more at risk compared to the .DS_Store files. For this reason alone I think that the single-database method is not a good risk to take, at least in an all-or-nothing fashion.
I think a hybrid method would be a better solution to the problem. For internal Macintosh drives, there's no reason to eschew .DS_Store files. Windows users might see them when they connect to the Macintosh, but they shouldn't really have a problem with that because it's not their hard disk. For network drives, however, a database file (perhaps one per volume, to combat corruption) would make more sense. These would be stored in the Mac user's local home directory. .DS_Store files wouldn't be created on the network volume, and the Mac user could still retain his per-window settings for network volumes.
Incidentally, if you were wondering, you can already turn off the creation of .DS_Store files on network volumes in Mac OS X. Just in case Windows users are already all over you about your .DS_Store files.
Technological Supernova Rants Older Newer Post a Comment