[perl #38146] [TODO] OS.pmc

Will Coleda

unread,

Jan 3, 2006, 9:03:31 PM1/3/06

to bugs-bi...@rt.perl.org

# New Ticket Created by Will Coleda
# Please include the string: [perl #38146]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38146 >

OS.pmc should provide both a:

copy(source_file,target)

And a

copy(array_of_source_files,targetDir)

Alberto Simoes via RT

unread,

Jan 6, 2006, 4:11:43 PM1/6/06

to perl6-i...@perl.org

> [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.

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.
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.
Alberto

Joshua Juran

unread,

Jan 6, 2006, 11:17:49 PM1/6/06

to parrotbug...@parrotcode.org, Perl 6 Internals

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

Joshua Isom

unread,

Jan 7, 2006, 12:53:51 AM1/7/06

to perl6-i...@perl.org

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.

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.

Bob Rogers

unread,

Jan 7, 2006, 10:59:10 AM1/7/06

to Joshua Isom, perl6-i...@perl.org

From: Joshua Isom <lon...@ritalin.shout.net>
Date: Fri, 6 Jan 2006 23:53:51 -0600

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.

Thinking in another direction, why is there only one OS class? Seems to
me it would be cleaner to implement such things as file copy if there
were a class hierarchy that reflected OS family relationships.

Even more importantly, having multiple classes would make it much
easier for language implementors to define OS-independent interfaces for
language-specific features. This would then be a simple matter of
writing multimethods that dispatch on the right OS subclasses, without
worrying about which class actually gets instantiated.

My $0.02,

-- Bob Rogers
http://rgrjr.dyndns.org/

Alberto Simões

unread,

Jan 7, 2006, 1:01:30 PM1/7/06

to Bob Rogers, Joshua Isom, perl6-i...@perl.org

I think we might have a bigger problem than a copy per OS. I think we
will have a copy per FileSystem if we get too detailed in its process.

Alberto

--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal

Joshua Hoblitt

unread,

Jan 7, 2006, 6:04:29 PM1/7/06

to Alberto Sim?es, Bob Rogers, Joshua Isom, perl6-i...@perl.org

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).

Cheers,

-J

--

Chip Salzenberg

unread,

Jan 10, 2006, 10:29:16 PM1/10/06

to Joshua Hoblitt, Alberto Sim?es, Bob Rogers, Joshua Isom, perl6-i...@perl.org

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.

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 <ch...@pobox.com>