Can anyone confirm if this will work in Panther? Or if there is another method that will stop he .DS_Store files in panther?

Yes it does work on Panther.

Why don't you just try it fer chrissakes. It's not like it will take you more than 5 seconds to cut and paste the SINGLE command into your terminal window. I've heard of hand-holding but this is ridiculous.

That's true, but now every Panther user who comes along can save themselves that five seconds. It's not just thirteenva who can use that information.

No, it does not work on Panther.

Is there a similar tip for stopping these files appearing on mounted non-Apple volumes, such as memory sticks, digital camera's, my Sony PSP and my SonyEricsson K750i mobile phone?

Whenever I mount one of these on my desktop and copy/modify any files, the Mac OS (un)helpfully creates all these hidden files, which obviously the PSP and K750 don't understand.

Currently I have to use a third party 'cleaner' application to manually delete all these files before un-mounting the device. If it was possible to stop them being created in the first place it would help immensely.

Yes. Or mp3 players for those of us who haven't joined the iPod "revolution".

What third party cleaner do you use? I've had mixed results and even resorted to using VirtualPC for keeping my MemoryStick clean, which isn't just an inconvenience in my case, those files cause a direct conflict.

find /Volumes/PSP/ | grep -ir '\(\._\..*\|\.AppleDouble\|\.AppleDesktop\|ws_ftp\.log\|Thumbs\.db\|pspbrwse\.jbf\)$' \
| sed 's/^\(.*\)$/rm -f "\1"/' | /bin/sh

You may try to use FinderCleaner:

http://www.macupdate.com/info.php/id/16996

It's a freeware utility that removes such files before ejecting an external device.

Cheers

---
:: Jedi Knight ::
-- Mac Rules! --

Well thank GOD for this hint. Now could someone tell me *why* this isn't the default?

Furthermore, I agree with the other poster - if there's a way to keep it from littering my flash devices as well, I'd be all ears.

Well, if you're only using AFP volumes, you might actually /want/ them to be created.

I'd love to be able to disable them for everything but AFP, but that doesn't appear to be an option.

More Info:
In theory there are 3 sets of preference locations on a mac:
~/Library/Preferences
/Library/Preferences
/Network/Library/Preferences

The Pref system is supposed to use a known order of searching to find a pref, starting at the top of the list, working its way down (I don't know if the order I gave is the search order, btw). If none of the locations have the pref set, then a default, choosen by the app is used.

This would allow The same file to exist on all three locations, but allow an admin to set some network wide prefs in the /Network folder (not necessarily all the prefs either, just one key-value pair), somebody to set some prefs for the machine, and then the user to override the prefs for when they are logged in.

I actually have never seen the /Network prefs used, but I've also never been in a managed macintosh network environment. Whether or not the network domain ever got implemented I don't know, and how the /Network/Library folder would even get created or accessed, I am unsure.

Just thought it would be interesting to see this pref get set in the /network domain, so each individual user in the company would not have to set it each time they got a new mac or re-installed the OS, etc.

links:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Concepts/UserPreferences.html

[ Reply to This | # ]

I need to find a way to do this for my work, i cant seem how to set a preference qualifier when i write the plist

if ANYONE knows how to do this, so any user loging on doesnt leave .ds_stores everywhere, please let me know

Excellent! Now, if only I could get it to stop saving ._filename.htm files every time I edit filename.htm over the network using BBEdit...

Turn off the BBEdit preference to save state, it adds a resource fork to the file, which is what those ._files are (I think) -

Text Files: Saving - Save Document State

Too bad you can't do this per document (I couldn't find it if there is), there are some files I would like to save state, but mostly I don't ( or don't care).

More recent versions of BBEdit (at least since version 8) store document state in the preference file instead of the document's resource fork, so this should no longer be a concern.

It is still a 'concern', because if you're not on an HFS volume, the type and creator code are also stored in the .DS_Store--it's not just the resource fork in there, but also meta data.

I have turned off 'save document state' in BBEdit 8.2.4 and I still get the dot underscore files when saving to our Win2000 Server. Can anyone verify that this advice actually works for them?

Hah,

Where I used to work we called it 'Mac Spoor'

---
In /dev/null, no one can hear you scream

[ Reply to This | # ]

\

---
In /dev/null, no one can hear you scream

[ Reply to This | # ]

---
In /dev/null, no one can hear you scream

[ Reply to This | # ]

What are you going to do if someone does 'ln -s / ._foo' and then you run this script?

In the case of files, perhaps I will have to restrict the filetype to "file" as opposed to "directory", or perhaps there's an option (probably, but not at my computer currently) to not follow symlinks.

Good point, however. Obviously the ultimate ds_store removal one-liner is still in active development...

---
In /dev/null, no one can hear you scream

Obviously the ultimate ds_store removal one-liner is still in active development...

find . -name .DS_Store -print -delete

 -P     Never follow symbolic links.  This  is  the  default  behaviour.
        When find examines or prints information a file, and the file is
        a symbolic link, the information used shall be  taken  from  the
        properties of the symbolic link itself.

While I agree this behaviour is annoying, opening up write access to the root of a file server volume can be extremely unwise! Hence Apple's decision to do it per directory...

Well, maybe not. Files prefixed with "._" contain all of the metadata for their un-prefixed partner that the native volume format cannot contain in a single file: resource forks, flags, dates, and now in Tiger, extended attributes.

You can run into nasty side effects if you always remove them. Although resource forks should be a thing of the past now, extended attributes will probably be of substantial use in the not so distant future.

---

/elander

Finder should store all this info (.DS_Store, ._resourcefork) in the root of the drive

Not a good idea. Less privileged users should not have have write privileges to the root of shared drives such as server volumes.

So, Finder writes to more appropriate paths.

Attempts to write to the root of a volume can be terribly problematic. See for example WebDAV (PLIP #187) and Microsoft Office 2004 and related links.

[ Reply to This | # ]

---
Slumming at http://www.beatnikpad.com/

[ Reply to This | # ]

Initially, this didn't work for me. After reading the original Apple technote, it occurred to me that perhaps the generated plist file wasn't going to the correct place. Though it was in my user's Preferences, it was not in the system preferences.

I tried copying the newly created ~/Library/Preferences/com.apple.desktopservices.plist to the main system preferences folder: /Library/Preferences/. Then restarted my computer.

Now it works.

With the original suggestion, would it be possible that the user needs to be root before generating the defaults command?

A Little History

Interestingly enough, this is not a new problem. In fact, it may be one of the oldest problems of all the Apple operating systems!

Way back in the early days, just after the stone wheel and before sliced-bread, we had portable disks with the enormous storage capacity of 800 KB! As Apple introduced a GUI desktop to the Apple II line, the OS used to leave similar files all over the place. We referred to them as Finder Turds. Because storage was such a tight commodity, these little files were enormously unpopular, and people complained bitterly about them. Indeed, there was quite the movement to wipe them out, just as we are seeing here.

You think the newest generation of Apple engineers would have learned from the previous generations.

<blockquote>Initially, this didn't work for me. After reading the original Apple technote, it occurred to me that perhaps the generated plist file wasn't going to the correct place. Though it was in my user's Preferences, it was not in the system preferences.

I tried copying the newly created ~/Library/Preferences/com.apple.desktopservices.plist to the main system preferences folder: /Library/Preferences/. Then restarted my computer.</blockquote>

At first I thought it wasn't working so I did the same, copied the ~/Library... file up to /Library... (there was no such file there before) but now I figure that I'm looking at the wrong files on the server and confusing myself. I don't get .DS_Store files and did not before I copied the prefs file upwards either.

But I always do get the ._AppleDouble files (ie: image.jpg and ._image.jpg) though and in the case of small images they're more than double the size of the actual image.

I've searched around and found no way to turn these off and some controversy about whether they can be safely deleted or not. I'm thinking that for Linux purposes when I don't care about bringing the files back into the Mac it doesn't matter.

Any thoughts on this? Anyone?

But I always do get the ._AppleDouble files (ie: image.jpg and ._image.jpg) though and in the case of small images they're more than double the size of the actual image. I've searched around and found no way to turn these off and some controversy about whether they can be safely deleted or not. I'm thinking that for Linux purposes when I don't care about bringing the files back into the Mac it doesn't matter.

Those are thumbnails, and/or image previews. Try setting what ever graphics application you are using to not save a preview/thumbnail. That way there wont be any resource forks in the files.

---
G4/Digital Audio/1GHz, 1 GB, Mac OS X 10.4.8 • www.david-schwab.com

[ Reply to This | # ]

"Even with this hint in place, the .DS_Store files will continue to be created on local volumes (which is a good thing). "

Dammit, why do people make excuses for Apple? They'll only fix things when enough people complain.
As one earlier poster said, creating .DS_Store files is NOT a good thing. It is a stupid pathetic hack, the sort of thing an amateur programmer would come up with. There are a dozen different ways one can imagine the Finder storing the various things it wants to know about how to display a particular directory, all of which don't have this horrible impact on the user.

The fact of the matter is that, five years after OS X was released, the Finder is still a POS. Readers of this website should get serious about FTFF --- whenever you have a chance to meet with an Apple person, raise the issue and don't let go. It is very nice that Apple has smart people working on file systems, metadata, data bases and similar low level issues, but how about they spend three months talking to the losers on the Finder team and explaining to them how to solve this problem properly?

obviously you need to get hired as a manager on the finder team and show them how it should be fixed.

I am being serious, and only a little sarcastic.

while you are at it, get them to improve the threading related to network activity. (I have submitted feedback with suggestions on possible ways to do this, and have applied for jobs at apple, but so far, neither has happened)

As one earlier poster said, creating .DS_Store files is NOT a good thing. It is a stupid pathetic hack, the sort of thing an amateur programmer would come up with. There are a dozen different ways one can imagine the Finder storing the various things it wants to know about how to display a particular directory, all of which don't have this horrible impact on the user.

On Thu, Jul 14 '05 at 08:30 AM, thoughton wrote:

> Why don't you just try it fer chrissakes. It's not like it will take you more than 5
> seconds to cut and paste the SINGLE command into your terminal window. I've
> heard of hand-holding but this is ridiculous.

Did someone get up on the wrong side of the bed? Get a grip - you'll live longer.

Maybe he *did* try it, and for some reason it didn't work, and rather than assuming it just doesn't work on Panther, figured he'd ask here. I'll go ahead and answer his question in a more polite way, since you seem to be unable to do it:

I can verify that this hint does not appear to work in 10.3.9 for me. I have:

# defaults read com.apple.desktopservices DSDontWriteNetworkStores
true

Yet when I connect to a shared folder (netatalk share on a SuSE Linux machine), Mac OS X still creates .DS_Store folders.

---
-monoclast

> I can verify that this hint does not appear to work in 10.3.9 for me. I have:
>
> # defaults read com.apple.desktopservices DSDontWriteNetworkStores
> true
>
> Yet when I connect to a shared folder (netatalk share on a SuSE Linux machine), Mac OS X still creates .DS_Store folders.

Likewise. I have OS X 10.3.9 and I created com.apple.desktopservices.plist in the system and user preferences folders (/Library/Preferences and ~/Library/Preferences). I rebooted and verified the setting using the command you posted.

Apple's advice simply does not work for me, either. I still get .DS_store files all over the place on the SMB share I use.

It's the resource fork of the files. It doesn't matter if you're moving them to linux, unless some mac program has added metadata to the resource fork.

Can it be that this is not working for networked homedirectories? We have this situation here, and .DS_Store files are still created / modified as before...

It should be noted that .DS_Store is very similar in purpose to the thumbs.db file on WinXP.

Thumbnails are stored individually in the resource fork of the file, which is stored as ._filename on non-HFS+, non-AFP volumes. Windows's thumbs.db file only holds thumbnail images for the pictures in that directory.

Maybe the Finder just needs an option to "Store window and icon placement information only on HFS+ and AFP volumes"?

[ Reply to This | # ]

is there a way to resolve this in 10.5.*?

Sorry but I am new to being my own IT person. What is the "terminal" or how do I find it to put in the code?

Gianna