An aside: I suspect that OS.pmc is going to grow beyond maintainability
(and fast loading) in the manner of Perl's POSIX module. But for now,
it's absolutely great that we're collecting each portability hack into
a single implementation.
On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wrote:
> I think it's prudent that OS.pmc's default copy() method behaves in the
> same way as File::Copy::copy() as this is likely the lowest possible
> common denominator across platforms (note that I said behavior, not
> implementation). This is sufficient for the majority of file copy tasks
> and will make prevent most people from having to worry about portability
> issues. 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
...
)
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.
Come to think of it, Perl 5 could use one of these. And somebody
should check with the p6 guys to see what they think of it ... they
might be in a mood to (re)specify filesystem manipulation.
--
Chip Salzenberg <[EMAIL PROTECTED]>
