develooper Front page | perl.perl5.porters | Postings from June 2008

Re: [PATCH] File::Copy & permission bits.

Thread Previous | Thread Next
Charles Bailey
June 8, 2008 19:11
Re: [PATCH] File::Copy & permission bits.
Message ID:
On Sat, Jun 7, 2008 at 12:31 PM,  <> wrote:
> On Sat, Jun 07, 2008 at 11:44:02AM -0400, Charles Bailey wrote:
> [ .. Snip .. ]
>> 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.
>> - If we want to make extended semantics available, put them in
>> syscopy() or cp(), and break the identity on POSIXy systems between
>> these routines and copy().  I see that as less of a problem than
>> changing copy() because I think most programmers who chose to use
>> syscopy() or cp() are indicating their intention to use a particular
>> functionality. (This is less so for cp(), but I'd guess that most
>> people who choose this alias wouldn't be all that hurt if it behaved
>> like cp(1)).
>> - If the standard is not to break backwards compatibility at all, we
>> should implement new extensions in File::Copy::Foo, with clear
>> warnings in the docs that users of these platform-specific packages
>> should not expect their code to be portable.
>> If there's a conensus that one of these alternate solutions is
>> appropriate and Abigail is too busy to update her change, I'm happy to
>> supply a patch to DTRT.
> As for the intention of File::Copy to replace "system cp $to $from",
> IMO, it has utterly failed, one of the reasons being it not respecting
> the permission bits of the origin. In fact, if I inherit code that
> uses File::Copy, I take my chainsaw, and replace its copy() calls with
> "system cp".

Good to know.  It has been historically successful in meeting my
initial goal: allowing Perl to install itself and modules without
recourse to system().  I'm not really sure what the uptake of
platform-specific syscopy() has been; its initial goal was to
accommodate VMS- and Win32-specific file sructure.

If you (or anyone else reading) had a free hand to rewrite
Flle::Copy::cp(), is there anything besides copying permission bits
you'd want?  Would it be worth thinking about timestamps, ownership,
links, something else as options?

> I'm also fine with leaving File::Copy not respecting permission bits
> at all. But then I'd like to see a clear warning in the documentation
> that File::Copy::copy isn't a replacement for "system cp", but behaves
> differently. And I'll keep ranting against anyway claiming I should
> favour File::Copy over "system cp".

Seems like more documentation is worthwhile, regardless of the
behavior that's finally chosen.

I guess we wait and see what consensus develops.

Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About