On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote:
On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote:
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?
So it'd probably be best to put it in os.pmc with checks to know which
operating system it's compiled for. That way, each language
implementation that includes an operator to copy a file can do so more
safely. Isn't part of the point of parrot to make writing a compiler
not be system dependent? In fact, if perl had a copy operator instead
of doing the open/print combo, the resource fork issue on Macs would be
taken care of.
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
Another thing is that moving a file across file systems isn't
guaranteed to work(I don't know if it is on any platform), and to do so
would require copying. Implementing a copy that supported host
specific features in os.pmc would help ease that problem. If copy were
implemented in pir, and rename were implemented in os.pmc, a problem
would arise. The mv command takes care of this, and in my view, for
convenience, so should any rename command in os.pmc.
