On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
[coke - Tue Jan 03 18:03:31 2006]:
OS.pmc should provide both a:
copy(source_file,target)
And a
copy(array_of_source_files,targetDir)
This needs some more discussion. If we look to Perl, for instance, it
doesn't have a built-in copy. You should use either a module, or open
both files, copy contents, and close both files.
You assume cp semantics. What about preserving metadata? What about
multiple forks? What about per-file properties that are invented after
you ship your code? And what if the source and destination are on the
same file server?
Thus, what I ask if we should have a copy method on OS.pmc.
Basically, I think we have three hipothesis:
1) do not implement copy at all.
You are in a maze of twisty little ad-hoc, informally-specified
bug-ridden slow implementations of file copy, all different.
2) implement it under os.pmc, in C
3) implement it somewhere else in PIR
Given that we have (I think) all the needed instructions in PIR, it
will
be a lot easier to make copy portable using the third choice... but I'm
not sure if Parrot will ship with a PIR library...
Please, share your ideas.
I'd like to see every OS get a chance to provide its own file copier.
This is important to Mac users, since resource forks may exist and the
AppleShare protocol (AFP) allows for intra-server file copy. The same
arguments also apply to other file systems.
The Genie kernel (part of Lamp, a Unix-like environment on Mac OS) has
a copyfile() system call for just this purpose. The knowledge of how
to copy a file correctly in a Mac environment (which is non-trivial) is
encapsulated in a single place, and usable by any program, either
directly through the system call, through cp (for shell scripts), or
through a module-loading interpreter.
For more typical systems, supply copyfile() in a library as you would a
missing kernel call.
This usage assumes that copyfile() blocks until completion. Clearly
there will be a desire for a concurrent processing mode as well.
Josh
