[dark3lf]

Can someone please explain to me what .DS_Store is? I use Sharity to connect to the CIFS/SMB workgroups at work, and it works well. The only problem is that wherever there is a writable directory (which is a LOT of places), i leave multiple instances of a file called .DS_Store. It is starting to cheeze my co-workers off, because I left over 550 instances of this file in directories all over the place. They know exactly where I've been, and for some of the files, I am the only one who can actually delete them for some reason. They've banned me from using OS X PB on SMB shares.

That's the equivalent of the desktop database file in OS X.

There's no way to turn it off... Sort of like when you use a PC zip disk and your Mac leaves resource information that's visible in the PC filesystem.

[gabrielf]

This is something that sucks with macos, that it leaves all these strange files on pc disks. Why can't macos just store the desktop databases on the mac volume instead of on the pc volume? It would be so much cleaner. If I mount a pc volume (floppy, zip, network drive) and copy a file from or to it (or just look at the content) I don't want anything else being copied or created on that floppy.

/Gabbe

[Alex Duffield]

I agree! We should ALL tell apple. that is what the feedback is for.

As for network drives, if anouther user is also using the drive, he/she overwrites the .DS_Store file with his/her window settings.. next timew I open the window, it is NOT as I left it, so the point of the file is usless. These settings hould be stored in a database on the system some plase, so they are "user" based, and not "folder" based

[kiwi]

.DS_Store files are really @#%$@$# (I can't find a word strong enough). They must be removed from OS X. They not only consume disks (I don't talk about the space but the number of files) and pollute volumes (removable media from other platforms, mounted network directories...), they also cause security problems. These files have "666" modes in order to work. That means that anyone is able to modify (corrupt) them and fill the disks anonymously without restriction (that's a important issue in shared environments).

They MUST disappear. I don't know exactly what their purpose is, but if some information have to be stored on disk, they should be in one global file (like under OS 9) by using a deamon to avoid the "666" modes. Maybe each user should also own its own set of data. There should then be one file for each user in its preferences.

I have already sent a feedback to Apple to complain about these files. I think I will send another one about the issue hilited by dark3lf. I recommand to do the same.

[dark3lf]

Originally posted by kiwi:
.DS_Store files are really @#%$@$# (I can't find a word strong enough). They must be removed from OS X. They not only consume disks (I don't talk about the space but the number of files) and pollute volumes (removable media from other platforms, mounted network directories...), they also cause security problems. These files have "666" modes in order to work. That means that anyone is able to modify (corrupt) them and fill the disks anonymously without restriction (that's a important issue in shared environments).

They MUST disappear. I don't know exactly what their purpose is, but if some information have to be stored on disk, they should be in one global file (like under OS 9) by using a deamon to avoid the "666" modes. Maybe each user should also own its own set of data. There should then be one file for each user in its preferences.

Exactly, I can imagine a scenerio where these files could be used to infect the host computer or corrupt the entire filesystem. They don't really seem to do anything anyway (on a HFS+ volume running OSX), if I delete it, absolutley nothing happens, it's business as usual. It does, however, get re-spawned very soon after I've deleted though. And has anyone noticed that they've started showing up in SIT archives? So you could have .DS_Store files from someone else's computer lying around!! (shiverrrrrrrr)

I have already sent a feedback to Apple to complain about these files. I think I will send another one about the issue hilited by dark3lf. I recommand to do the same.

Done and done

[Angus_D]

yes, and I'm sure they will also hack the CIA and help corrupt the nation's youngsters!
seriously, folks, they're not much of a problem. HFS+ has a block size of oooh 4k normally, doesn't it? so, what, 1000 of these files is about 4mb? On a 10gb drive i don't see the problem.

[Chaaaosss]

VERY GOOD POINT! It's like you know... 1,000 people who believe that Bush will make a good President... yeah.. they only take up a little space physically... but then their mere presence corrupts everything good and true about this wonderful country of ours!

Oops. Off topic. .DS_Store files suck.

[kiwi]

It seems that you didn't read what I wrote earlier. It's obvious that disk space isn't an issue. I'm talking about the amount of files. I currently have 8,100 directories on my 6GB hard disk. That means 8,100 potential .DS_Store files. I don't care about the 30 or 40 MB wasted by them. Just run Norton Utility or any other application that parses the files on disk (we hopefully have HFS that is a fast filesystem), and you will discover that you hate these damned files. Those are pure waste...

Moreover, I can't find any good reason for those files to exist. We all want OS X to be the best OS. If this problem isn't "extremely" bad, that doesn't justify letting it exist. Having many, many files on disk is not good. It causes performance drop and it is not user-friendly. I loved resources for that (fast find, fast file copies, 1 file = 1 application). Apple chose to follow another way. OK. But don't make the situation worse, just get rid of these useless files.

Originally posted by kiwi:
Moreover, I can't find any good reason for those files to exist.

They are for storing metadata, like folder size/position, icon position,
label color, etc. This lets us have lots of user-friendly behaviors in
the OS without having to invent a whole new filesystem to support it.

I *do* think that the .DS_Store file should *only* be written to *local*
volumes, and *never* to network volumes (let the machines to which those
network volumes are local be the ones which write those files). As for
removable volumes, there needs to be a volume-root file which determines
whether it's ok or not to write the metadata to its subdirectories.

-Walter

[kiwi]

Originally posted by Boodlums:
They are for storing metadata, like folder size/position, icon position,
label color, etc. This lets us have lots of user-friendly behaviors in
the OS without having to invent a whole new filesystem to support it.

These data already existed under classic MacOS, and I have never seen such files to store them.

This kind of data should depend of the user logged. Putting one file in each folder is the worst method, files can't be shared between users without issues. These data should then be stored in each user account.

Does someone know exactly what is stored in .DS_Store?

Originally posted by kiwi:
These data already existed under classic MacOS, and I have never seen such files to store them.

You're right. There is a special place in the HFS and HFS+ where these kind of data is stored. Therefore .DS_Store files shouldn't be necessary on HFS/HFS+ volumes. If you delete them nothing happens, because the data these files contain is redundant. I think, .DS_Store files make only sense on foreign file systems (like UFS that don't know about finder attributes / meta data), where the data must (?) be preserved.

[kiwi]

Originally posted by Frank Vercruesse:
You're right. There is a special place in the HFS and HFS+ where these kind of data is stored. Therefore .DS_Store files shouldn't be necessary on HFS/HFS+ volumes. If you delete them nothing happens, because the data these files contain is redundant.

I had forgotten this point. Anyone can take a look at http://developer.apple.com/technotes/tn/tn1150.html and check.
HFS+ is better than HFS and allow to store meta data extension. No need to resort with another file system. It is the proper way to store global data. Apple should also use it to identify the bundle instead of using the name of the folder.

I think, .DS_Store files make only sense on foreign file systems (like UFS that don't know about finder attributes / meta data), where the data must (?) be preserved.

I agree with you. So why are the files created on HFS+ disk? Is it a bug?

I'm not really anxious about this story. Icon and window placement isn't managed correctly under OS X. Apple has still work to do. I hope they are reading feedback carefuly and they will fix all these issues.

[Boodlums]

Originally posted by kiwi:
I agree with you. So why are the files created on HFS+ disk?

The .DS_Store file is extensible, and so can provide *more* than HFS+.
From the HI-Developers list:

Date: Mon, 29 May 2000 08:33:48 -0700
From: Eric Schlegel
Subject: Re: Finder Attributes and Mac OS X

On 5/28/00 at 10:59 PM, Walter Ian Kaye wrote:
> As long as it's in a new data structure, can we increase
> the # of bits? Seven colors/categories has never been
> enough. I've always wanted 256 possible categories...

We mentioned at WWDC that we were planning to allow more
than seven labels. This isn't implemented yet, as far as I
know, and that's all the information I have about it.

-eric

[kiwi]

Originally posted by Boodlums:
The .DS_Store file is extensible, and so can provide *more* than HFS+.

HFS+ is already extensible. HFS has fixed attributes, not HFS+. That could be the explanation, but the files don't need tousands of attributes, and i'm sure HFS+ can handle all of them.

What is the list which this information came from?

[absmiths]

Originally posted by Chaaaosss:
...
Oops. Off topic. .DS_Store files suck.[/B]

Hey, Cha3os3, keep your stupid political opinions to yourself and try to keep your feeble mind on topic.

.DS_Store files are certainly annoying - but as far as the security aspect goes Apple has no liability since anyone claiming loss or breach would have to explain why they are using a Beta OS for critical information.

My guess is that an engineer at Apple had to write a quick hack to make some operation of the Finder work and that was the solution. I think Apple will handle this the "Right" way by release time.

Just my $.025 worth.

[alexkent]

ok, i've got a use for .ds_store
(its kinda lame but...)

you know magazine cover cd's that have images made of many icons in the finder window?? well, if the icon data was stored in a local user dependant file on the local machine thenthese wouldn't work.

ooo, so obviously they are vital.
we must have them.

No actually, your fight, they suck. They make a mess of my NT server's disks.