|
|
APPLE! Suggested Feature. Plus, Removal Tip
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.) ---
NOTE: Parentheses are missing escapes
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.---
::sigh:: So was the semicolon!
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 ---
APPLE! Suggested Feature. Plus, Removal Tip
What are you going to do if someone does 'ln -s / ._foo' and then you run this script?
Good point.
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.
Obviously the ultimate ds_store removal one-liner is still in active development...What is wrong with:
APPLE! Suggested Feature. Plus, Removal Tip
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.
APPLE! Suggested Feature. Plus, Removal Tip
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...
APPLE! Suggested Feature. Plus, Removal Tip
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.
APPLE! Suggested Feature. Plus, Removal Tip
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. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.19 seconds |
|