Re: Odd Finder Behavior
Re: Odd Finder Behavior
- Subject: Re: Odd Finder Behavior
- From: Christopher Nebel <email@hidden>
- Date: Tue, 5 Dec 2006 12:02:30 -0800
On Dec 5, 2006, at 2:20 AM, Peter Waibel wrote:
Has anyone suggestion how to savely delete files (data and resource
fork) on a mounted volume without using finder scripting?
You can use rm.
I do use rm on my own files
but I'm still hesitating to use rm in scripts that are used by others.
The reason why I'm hesitating is that I do not understand what rm
really does.
That's not unreasonable, because the answer to that question changed
some in Tiger. These days, rm(1) deletes the file, including any sort
of extended meta-data it has, regardless of the type of file system
it's on. This used to not be the case -- file systems that don't
support extended meta-data such as resource forks store the extended
information as a sibling file [1], and rm(1) would only delete the
primary one.
Therefore: if you can assume Tiger, then don't worry about it, it's
all good. If not, then you probably don't have to worry about it,
because most people only use HFS+ disks, for which the problem doesn't
apply. (However, that depends some on who your customers are.)
--Chris Nebel
AppleScript Engineering
[1] The sibling file is named the same as the original with "._"
prepended. NFS falls into this category, as do some kinds of Windows
shares, though I couldn't swear to that. HFS+, which is the default
volume format for Mac OS X, does not have this issue, nor does AFP,
which is the protocol for Mac OS X file sharing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/mailman//archives/applescript-users
This email sent to email@hidden