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