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

Re: One less File::Copy bug

Thread Previous | Thread Next
Craig A. Berry
May 1, 2008 11:21
Re: One less File::Copy bug
Message ID:
On Mon, Apr 28, 2008 at 5:22 AM, Johan Vromans <> wrote:
> Aristotle Pagaltzis <> writes:

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

It may not have optimal wording or clarity and it may be somewhat
out-of-date in relation to the current code, but you only think it's
stupid because you don't know what OS-specific attributes it's talking
about.  It's understandable you wouldn't since VMS is probably the
only supported OS that uses them.  The attributes in question are
stored in the file header and mostly describe the structure of the
contents of the file.  While Unix-style stream files are supported and
work just fine on VMS, that's only one of many options.  A simplified
view of things is that there may be metadata mixed in with the data of
the file, and the attributes describe what sort of metadata there are
and where to look for them when interpreting the file.

For example the file may be record-oriented, not stream-oriented, and
a record-oriented file may have either fixed-length records of a
particular size, or variable-length records with a fixed control field
at the beginning of each record specifying how long it is.  And/or the
file may have indexes.  A C program that copies such a file by doing a
simple fopen() of both source and target and fread()/fwrite() until
EOF is implicitly converting it to a stream-oriented file and
discarding all the attributes and metadata.  There are times when
that's what you want to do, but it should never be the default for
copying a file.  And it isn't on VMS, since File::Copy::copy uses
syscopy.  I'm almost positive this was the original impetus for
syscopy and the wording about preserving attributes was intentionally
vague in case any other types of attributes showed up and became of

A better description of what we currently have might look something
like this (though this probably fails to account for what syscopy does
on Win32):

File::Copy also provides the C<syscopy> routine, which copies the file
specified in the first parameter to the file specified in the second
parameter, preserving filesystem-specific structure and other
non-portable attributes on those systems that have them.  For Unix
systems, C<syscopy> is equivalent to the simple C<copy> routine (and
is not exportable) since Unix filesystems have no such attributes.

Now, back to what I think you're interested in.  Unix filesystems do
have timestamps and permission bits (anything else worth noting in the
file header?).  Should those be preserved by a file copy operation?
Should there be optional parameters to copy() and/or syscopy() to turn
those features on or off?  I would think copy() should do what cp does
(assuming it does the same thing on all unixish systems) and syscopy
should do more like what a backup or archiving program does, i.e.,
preserving the original attributes, but I have no particular expertise
in such things.  It does appear that even twelve or so years ago it
was deemed safer to add syscopy than to mess with the semantics of

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