On 2006–01–08, at 02:52, John Delacour wrote:
At 12:25 pm +1100 8/1/06, John Horner wrote:
Supplementary question. If you were moving, copying and renaming
files, would you use File::Copy instead of cp and mv?
Because by doing so you will make your script portable to Windows,
VMS, z/OS, Symbian ... However, I just checked, and the module does
not handle Mac OS X resource forks, so
You should first consider ditto if there is any chance your files
contain valuable resource forks.
% ditto --rsrc ...
No need to bother with this Mac OS X-specific wrinkle if you're
running Tiger -- from <http://www.apple.com/macosx/features/unix/>:
"Use command-line commands safely on HFS+ files. Utilities such as
cp, mv, tar, rsync now use the same standard APIs as Spotlight and
access control lists to handle resource forks properly."
So use File::Copy for portability across operating systems (provided
you know you'll never meet a resource fork on Mac OS), ditto for
portability across Mac OS X versions, or mv for portability across
UNIX versions (including Mac OS X 10.4, but not lower). Phew.
Looking at the POD, I find that
"File::Copy also provides the "syscopy" routine, which copies the
file specified in the first parameter to the file specified in the
second parameter, preserving OS-specific attributes and file structure."
Umm, no it doesn't on Mac OS X. However
"On Mac OS (Classic), "syscopy" calls "Mac::MoreFiles::FSpFileCopy",
if available."
As Tiger makes Mac::MoreFiles::FSpFileCopy available (previous
releases don't), and the function does indeed copy a file including
its resource fork (although it lost the icon for the file I'm testing
with -- maybe that's a Finder thing), I consider it a bug that
File::Copy does not use it if it can on Mac OS X. With your
permission, I'll raise a bug report.
--
Dominic Dunlop
