Front page | perl.perl5.porters |
Postings from June 2008
Re: [PATCH] File::Copy & permission bits.
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
June 9, 2008 06:02
Subject:
Re: [PATCH] File::Copy & permission bits.
Message ID:
c9ab31fc0806090602j6ebeb40fkf86eb2cebf1b6280@mail.gmail.com
On Sat, Jun 7, 2008 at 10:44 AM, Charles Bailey
<bailey.charles@gmail.com> wrote:
> On Fri, May 23, 2008 at 11:53 AM, Craig A. Berry
> <craig.a.berry@gmail.com> wrote:
>>
>> If, on the other hand, Perl should have its
>> own definition of the right thing to do and act the same on all
>> platforms, then this actually widens the gap between platforms.
> Even more belatedly following up, after several years away from p5p,
Welcome back. We need you :-).
> As time has passed, I think a few changes in File::Copy's history have
> muddied the waters somewhat:
Indeed. But a bit of archive diving indicates that it's always had a
bit of an identity crisis. Way back at patch number #1 (i.e., 5.003
checked into Perforce) we see File::Copy::copy deciding to punt and
let syscopy do the heavy lifting under some circumstances:
27: if (($^O eq 'VMS' or $^O eq 'os2') && ref(\$to) ne 'GLOB' &&
28: !(defined ref $to and (ref($to) eq 'GLOB' ||
29: ref($to) eq 'FileHandle' || ref($to) eq 'VMS::Stdio')))
30: { return File::Copy::syscopy($_[0],$_[1]) }
and the number of those circumstances has just kept growing over the
years, with Win32 joining in about nine years ago:
http://public.activestate.com/cgi-bin/perlbrowse/p/3362
> * copy() and syscopy() have been the same thing under Unix.
For some time now I think they've been the same under most
circumstances for most platforms but for different reasons. Unix has
no syscopy, so whatever the pure-Perl File::Copy::copy does is what
Unix gets. But just about everybody who has a syscopy uses it to
implement File::Copy::copy *except* when copying from a handle or to a
handle, in which case the same code path is followed as under Unix.
> In a nutshell, then, my thoughts on the current patch:
> - The advantages in defaulting to POSIXy semantics don't outweight the
> disadvantages of breaking backward compatibility. As Craig points
> out, the breakage will be frequent in some environments.
What I meant by the widening of behavior between platforms is that
before Abigail's patch, the Unix copy() did roughly what the VMS and
Win32 syscopy() implementations do: it followed "new file" semantics
and created the target file with permissions inherited from the target
environment. Now it does more like what cp does, preserving the
permissions of the source file per Unix expectations, essentially
giving Unix the syscopy() it never had. Not sure what will, but
surely something. On the other hand, we're years behind the curve if
cross-platform consistency is a goal.
I don't like the fact that copying from a handle now gives different
behavior permissions-wise than copying from a filename, but that
inconsistency could be ironed out pretty easily.
The code has often been patched one platform at a time and really
needs an overhaul with all the variations in mind.
Thread Previous
|
Thread Next