Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'APPLE! Suggested Feature. Plus, Removal Tip' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
APPLE! Suggested Feature. Plus, Removal Tip
Authored by: Lectrick on Jul 13, '05 02:37:53PM
Good Lord, the Finder should store all this info (.DS_Store, ._resourcefork) in the root of the drive (perhaps analogous to OS 9's DesktopDB and DesktopDF) and transfer it with the file if requested and that's it. Peppering every damn directory with this info is an extremely ugly (and wasteful... each file takes up to two 4k disk blocks even though it's a 5k file or so) way to go about storing Finder-specific information.

If that is not an option, we should at least be able to disable this "feature" on a drive-by-drive (or network-share-by-network-share) basis. I don't want my iPod Shuffle (which I use at clients who are unfortunately on Windows) to be peppered with these files, at all! (I wouldn't mind a single dot-file at the root level, though.)

Meanwhile there is always this command, which you can make into a dropscript and make drag and drop:

find "$@" \( -name ".DS_Store" -or -name ".Trashes" -or -name "._*" \) -exec rm -rf "{}" \; -prune

This will remove all .DS_Store, .Trashes, and dot-underscore-prefixed resource fork files from a given directory and its children. (If you are running it by itself as opposed to inside a dropscript app, change "$@" to "." and CD to the appropriate drive first. Remaining tweaking is left as an exercise for the reader.)

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

[ Reply to This | # ]

NOTE: Parentheses are missing escapes
Authored by: Lectrick on Jul 13, '05 02:42:08PM
Damn it, the webpage removed the
\
escape character before the ( and ) characters, above- even though I specified it as tagged code! It will not work without that. If it is possible for an editor to change that, please do.

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

[ Reply to This | # ]

::sigh:: So was the semicolon!
Authored by: Lectrick on Jul 13, '05 02:44:24PM
Ugh, web form encoding, grrr.

Please also put a backslash before the semicolon in my original post (as well as before the parentheses). Again, if an editor can tweak this post-post, please do.

Peter

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

[ Reply to This | # ]

APPLE! Suggested Feature. Plus, Removal Tip
Authored by: bobbob on Jul 13, '05 04:02:17PM

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



[ Reply to This | # ]
Good point.
Authored by: Lectrick on Jul 13, '05 07:35:35PM

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



[ Reply to This | # ]
Good point.
Authored by: raider on Oct 13, '06 09:54:12AM
Obviously the ultimate ds_store removal one-liner is still in active development...
What is wrong with:

find . -name .DS_Store -print -delete


[ Reply to This | # ]
APPLE! Suggested Feature. Plus, Removal Tip
Authored by: Anonymous on Dec 05, '06 11:21:23AM
You're talking FUD. From man find:
 -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.
This means that, with find, even without the -P option, will instruct rm to operate on the symlink, not its target.

[ Reply to This | # ]
APPLE! Suggested Feature. Plus, Removal Tip
Authored by: Tom Robinson on Jul 14, '05 02:10:21AM

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...



[ Reply to This | # ]
APPLE! Suggested Feature. Plus, Removal Tip
Authored by: Elander on Jul 14, '05 09:40:26AM

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



[ Reply to This | # ]
APPLE! Suggested Feature. Plus, Removal Tip
Authored by: grahamperrin on Jan 02, '08 12:58:28PM
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 | # ]