File::Copy::copy With File Handles

[MaggotChild]

The documentation for File::Copy warns against using file handles as
arguments:

Note that passing in files as handles instead of names may lead
to
loss of information on some operating systems; it is
recommended
that you use file names whenever possible.

Does this refer to handles created with the older FileHandle module
(which is used in the module's synopsis), IO::Handle subclasses, or
both?

In either case what's the issue with handles that may lead to data
loss?

 

[MaggotChild]

On non-Unix systems (more specifically, on Win32 and I believe VMS)
File::Copy calls the system file-copy routine (CopyFile on Win32) if you
pass it filenames. This will preserve things like ACLs, extended
attributes, NTFS streams, and so on.

I had ignored the obvious and interpreted "loss of information" to
mean loss of the file's data, not necessarily metadata. Which lead to
me to believe that for some subtle reason File::Copy couldn't be used
reliably copy data streams. Thanks for the clarification.

 

[Ilya Zakharevich]

I had ignored the obvious and interpreted "loss of information" to
mean loss of the file's data, not necessarily metadata. Which lead to
me to believe that for some subtle reason File::Copy couldn't be used
reliably copy data streams. Thanks for the clarification.

The division into data/metadata is a tricky stuff. For example, "the
metadata" may contain the character encoding of a text file. If lost,
it would render the "data" completely useless.

Or the "thumbnail lower-resolution image" of a photo file. On
filesystems with arbitrary metadata allowed, the natural place for the
thumbnail image is in the metadata. On legacy filesystems, the viewer
program would be forced to either recalculate it each time, or put it
into the EXIF sections of the file (thus changing "THE DATA") or keep
it somewhere where it does not survive renaming of the file.

Yours,
Ilya