[Big Mac]

I'm trying to figure out why we need so many .DS_Store files polluting our OS X volumes. Maybe I'm missing the mark, but from what I can see, they're OS X's version of the OS 9 Desktop Database. While the Desktop Database isn't a perfect thing, at least the file is in one place. Not only are .DS_Stores ugly nuisances, they also are threatening to one's privacy, since they're in most every folder, listing the contents of that folder.

I understand that we can't have one Desktop Database/.DS_Store per volume anymore, since that's against the Multi-User ethos. However, do we really need a .DS_Store for every single folder? Why can't we have one, central .DS_Store for each user located in the user's Home folder? Wouldn't that be an infinitely superior solution? Yes, this is a small concern in grand scheme of things, but it's a concern to this Mac user nonetheless. The reason why I've used the Mac for twelve years is because of its elegance; the current .DS_Store solution is definitely not elegant. . . (And don't get me started on the lack of true meta-data support!)

[lucylawless]

I agree

[Scrod]

There is a better way--the way OS 9 did it. But I think you're a bit confused in that respect; the desktop database in OS 9 was just for storing file type, creator code and application associations, and which icons corresponded. OS 9's counterpart to the .DS_Store files exists in the HFS+ metadata. It didn't need to create invisible files in every folder because it just took advantage of the existing features of the file system. As Apple seems to want to make OS X more file system independent, they're using .DS_Store files instead.

[CharlesS]

Originally posted by Scrod:
<STRONG>There is a better way--the way OS 9 did it. But I think you're a bit confused in that respect; the desktop database in OS 9 was just for storing file type, creator code and application associations, and which icons corresponded. OS 9's counterpart to the .DS_Store files exists in the HFS+ metadata. It didn't need to create invisible files in every folder because it just took advantage of the existing features of the file system. As Apple seems to want to make OS X more file system independent, they're using .DS_Store files instead.</STRONG>

I think the reason the .DS_Store files replaced the creator code is that the creator code wasn't multi-user aware. Perhaps when the new file system that Apple could be developing with the hiring of the BFS engineer will have a solution to this...

[Drakino]

I agree, the hidden file situation on OS X is a mess. If I connect to a network share using AppleTalk, some info is put there. If I then connect to it via SMB, different files appear. I've stuck to AppleTalk now, and hide the files from SMB users using some samba options. Still not the best solution, but it works for now.

How does OS X work with these files stored on the network? Does each client know that it was made by another client, and append it's settings to it? Or does it simply read the .ds_store, apply the settings to that finder window, then save back any changes, leading to possible settings fights between users?

Apple Genius response was that the other systems on the network shouldn't be showing hidden files. Unfortunatly Windows clients use a hidden mark on the file, and not a system like Unix where dot files are hidden.

[ 05-01-2002: Message edited by: Drakino ]

[keston]

those .whatever files that dont show up in mac os and might be all well and good for me, really piss off the pc guys here at work who own/admin the win 95/nt/2000 boxes I connect to.

[Graymalkin]

Having the .DS_store files is a good idea, it lets OSX be file system independent. One of the problems with earlier versions of MacOS was its dependence on a particular file system in order to work properly. Using different file systems too often resulted in problems. Having any sort of folder configuration files stored as part of file system meta data is a bad idea. If you were to format your OSX in UFS you'd have to write some hacked driver in order to emulate the forked data structure of HFS in order to read and write folder confiuration data. Storing that data in a text file is a much simpler solution. If you had a central .DS_store file on the system what would you do when you had a removable disk you took from system to system? The central database would make an entry for the mount point which matched that particular disk. When you put another disk in it would either use the old database entry or have to write an entirely new one.

Writing data to a text confiruation file that is a couple of KB is trivial, writing configuration data to a central massive text file is quite a chore. I wouldn't want my system coming to a complete stop when I stuck a Zip disk in a drive and thus requiring an update of the central DS_store file. That being said however it is kind of crappy that Finder doesn't know the difference between a network mount and a local mount (even though this is the point of having mount points and a virtual file system). Finder needs an option to 1) realize it is working with a network mount and 2) not write a .DS_store file to said mount because it is a shared resource, not a localally owned resource. Multiple .DS_store files don't stink, the fact they are written to network shares stinks.

[Scrod]

Originally posted by CharlesS:
<STRONG>

I think the reason the .DS_Store files replaced the creator code is that the creator code wasn't multi-user aware. Perhaps when the new file system that Apple could be developing with the hiring of the BFS engineer will have a solution to this...</STRONG>

But, uh, the .DS_Store files don't store the creator code. That's still stored in the HFS+ metadata.

[frawgz]

Originally posted by lucylawless:
<STRONG>I agree</STRONG>

rofl..

This file system independence may be a good thing, lending Apple more flexibility as an investment in the future, but the .DS_Store's littering my hard drive as well as those of my Windows using counterparts are pretty annoying.

I assume that Apple is employing some half-assed methodology to be more "compatible" with the Windows world out there by using extensions instead of a real, robust metadata implementation. If that's true, then why is Mac OS X so reckless when it comes to dropping .DS_Store files all over Windows shares? This in addition to ._.Trashes and a menagerie of other .files.

[Voch]

I've got it! How's about a great big database like the Registry! .

Sorry. I'm at work right now havin' a good time with my crash-happy Acer Windows NT 4 box. Goin' home to my iBook right now...

Personally, I think the .DS_Store system is fine. A few apps need to deal with them better or ignore them outright, however.

Voch

[CharlesS]

Originally posted by Scrod:
<STRONG>

But, uh, the .DS_Store files don't store the creator code. That's still stored in the HFS+ metadata.</STRONG>

They store the reference to the app that the file will open with, which is the replacement for the creator code. Get info on a text file, and set it to open with Word instead of TextEdit or whatever your default is. It won't change the creator code, it will change the .DS_Store file.

[Developer]

Originally posted by CharlesS:
<STRONG>

They store the reference to the app that the file will open with, which is the replacement for the creator code. Get info on a text file, and set it to open with Word instead of TextEdit or whatever your default is. It won't change the creator code, it will change the .DS_Store file.</STRONG>

That's not true. This information is stored in a user open resource. This is stored in the resource fork on HFS and in a ._filename file on everything else.
The creator codes stays untouched and is indeed stored as HFS metadata.

The .DS_Store files only store window and icon placement information AFAIK.

[sjk]

Not to stray OT, but can someone explain where file comments are stored, and are there command-line utilities to modify/view them ({G,S}etFileInfo aren't it) instead of using Finder Show Info? Thanks.