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

Re: One less File::Copy bug

Thread Previous
From:
Abigail
Date:
April 28, 2008 05:17
Subject:
Re: One less File::Copy bug
Message ID:
20080428121741.GC15239@abigail.be
On Mon, Apr 28, 2008 at 02:05:17PM +0200, Aristotle Pagaltzis wrote:
> * Johan Vromans <jvromans@squirrel.nl> [2008-04-28 12:25]:
> > I would propose to a) cleary define the desired semantics of
> > copy and b) implement this. There is no need for a BUFFERSIZE
> > argument.
> 
> It lets the user trade speed for memory or vice versa. It???s not
> terribly useful, no, but it doesn???t exactly seem harmful either
> (modulo accepting 0 as a buffer size and successfully doing
> nothing in that case).
> 
> > There is no need for syscopy, copy should do the right job.
> 
> If File::Copy hadn???t been around for such a long time, agreed.
> However, the old API is what it is.
> 
> > There's no need for a cp alias.
> 
> I don???t see any reason to throw it out and to old Unix hands it???s
> nice to have around. What about it irks you?
> 
> > Increase the version number to 3.00. Automatically provide the
> > new semantics if the user explicitly requires the new version:
> >
> >  use File::Copy 3.0;
> 
> That is not functionally different from my proposal of allowing
> `syscopy` to be imported as `copy`, other than the fact that the
> import argument is a meaningless number as opposed to an at least
> somewhat descriptive name.
> 
> If you really want a new and simpler API, I submit that a new
> module name is a better way of handling that.

I once started working on a Unix::Copy module which would provide a
'cp' routine with most of the functionality of /bin/cp, using the
same API.

Then I decided that the "system cp" I was using already had all of this,
so why bother?

> module name is a better way of handling that. But the old
> File::Copy API should still be fixed, as far as it can be.
> 
> > As a side note: Wouldn't we all have a good laugh when, say,
> > Microsoft, wrote in the docs:
> >
> >  [...] also provides the syscopy routine, which copies [...]
> >  preserving OS-specific attributes and file structure. For Unix
> >  systems, this is equivalent to the simple copy routine, which
> >  doesn't preserve OS-specific attributes.
> >
> > This is just stupid.
> 
> Of course. That???s why I say that on Unix, `syscopy` should DTRT
> as far as it can.
> 
> It can???t do a complete job ??? eg. I doubt it???ll ever be able to
> copy XFS attributes of HFS+ resource forks. For apps to be able
> to copy files accurately without knowing the implementation
> details of every single possible filesystem, the filesystem has
> to provide a copy call. But Unix does not define such an
> interface, which is of course why `syscopy` has always been a
> synonym for `copy` on Unix.
> 
> But even so,the system interface situation is not going to
> improve, and at the same time, to a certain known extent the Unix
> model is universal across filesystems in Unix, so File::Copy is
> not merely punting but actively refusing to be helpful.


Unhelpful up to the point that it doesn't even export syscopy:

    $ perl -MFile::Copy=syscopy -e1
    "syscopy" is not exported by the File::Copy module
    Can't continue after import errors at -e line 0
    BEGIN failed--compilation aborted.
    $


Abigail

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About