On Jan 10, 2006, at 10:29 PM, Chip Salzenberg wrote:
On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wrote:
... More sophisticated behavior, like metadata replication, should
be left to another method (perhaps syscopy()) that has platform
specific
behavior(s).
My first thought was that if you're not going to copy any metadata at
all, then you're not looking at an OS method. But then then I
remembered that some operating systems might actually have
high-efficiency fast tricks for copying (e.g. the way Linux is going
with its splice() system call proposals). So OS is fine.
However, instead of shying away from the metadata problem, we should
embrace it. Define copying with metadata as a standard feature with a
standard interface. Something like:
metacopy($src, $dest,
owner => 0, # optional to copy
mtime => 1, # mandatory to copy
atime => undef, # forbidden to copy
...
)
I suggest using -1 to mean forbidden, and any false value to mean
optional.
This provides a portable way of expressing what you need and want.
If the current operating system can't accomodate you, you'll get a
failure or exception (not making any assumptions on that point).
Hm. If you say 'contents => undef', you might get a copying of
metadata _only_. Neat.
This reminds me of something that's been bothering me for a long time.
Since before System 7 (approaching two decades ago), Mac OS has had a
system call that exchanges the contents of two files. The purpose of
this call is to implement a 'safe save' strategy: When the user saves
a document, you create a temp file, write the new contents to it,
exchange with the existing file, and delete the temp file (which now
has the old contents). This is obviously better than just overwriting
the original file, since there's no risk of crashing or running out of
disk space leaving a truncated file. It's also better than using
rename(), because in the end it's the same file -- except for the
modification date, the metadata are preserved, including the file ID
number (read: inode) -- with different contents. If you rename()
instead of exchange/delete, you have a new file, and you have to set
all the metadata yourself, and you may not have the necessary knowledge
to do that. I suppose you could backup the original file and then
overwrite it, but you lose atomicity.
What bothers me is that I haven't seen exchange-files anywhere else.
Then again, Mac OS doesn't have move-and-rename-simultaneously, so
nobody's perfect.
Josh
