>As to the file comments - Mac files are alone in the world of
>computing - they are divided in two parts called 'forks', one is
>called the data fork the other is called the resource fork. The
>resource fork is where the file info and icon are stored, the data
>fork is where the data is stored (the picture, in the case of the
>jpeg). I'm conjecturing here
The conjecture is not quite correct.
Mac files are not quite alone, NTFS has a similar, more general concept,
called streams, which associates many named streams (like forks) with a
file. I'll use this more general framework to explain what the Mac is
doing.
The data fork is the main 'stream', which every OS understands and
accesses, for most of what we all consider the 'contents' of the file.
In NTFS this is the <fname>::$DATA stream.
The resource fork is the major repository for Mac-specific (often
interface-specific) information 'in' the file, and some information
'about' the file. 'In' includes menus, 68K CODE resources, icons,
dialogs, window positions, etc. 'About' includes 'BNDL' resources (for
associating file types openable by an application), creator resources,
'kind' resources, and 'open' resources (a new way of specifying file
types openable by an app). Resource forks are mainly cool because they
provide an OS-managed database of typed, IDed, and named objects
automatically associated with a file, though it has its limits. Note:
this does NOT include type and creator or comments (although they can be
inferred from the BNDL for applications). In NTFS, this is the
<fname>:AFP_Resource:$DATA stream.
The Apple File Protocol specifies some additional info (metadata) 'about'
files that is stored in the filesystem on a Mac and in the
<fname>:AFP_AfpInfo:$DATA stream on NTFS. This includes type, creator,
and possibly other stuff.
Also associated more loosely with a file are its comments. On the Mac,
these are stored in the desktop database (I believe) and associated with
the file, but not stored in or with the file. That's why it's easy to
overlook them when copying the file around, since it takes extra effort
to get and set them. In NTFS, these are stored in the
<fname>:COMMENTS:$DATA stream.
There are also various dates associated with a file: created, last
modified, last backed up, last accessed. Not all of these are maintained
by all OSes (or filesystems). UNIX ignores create dates, HFS ignores
access times and is funky about backup dates, NTFS has them all, and HFS+
has them all. These are not stored in any stream on NTFS nor in a fork
on the Mac, since they're part of the normal info associated with a file.
When sending such a complex thing across the network, it has to be
encapsulated somehow. MacBinary, AppleSingle, and BinHex are the most
common forms. They all put the above info into a single stream so the
other side can get it all back. Some programs don't fill in the comments
(like Fetch), even though there is room for them in the encapsulation
format (usuall MacBinary).
Now that the problem area has been better described, perhaps a Perl
expert (I'm a total novice) can explain how to get Net::FTP to do the
right thing. Maybe it can't. To totally preserve the information you
want (comments), you may need to BinHex or MacBinary the file locally
before sending it in binary mode, then get the server (you did say it is
a Mac?) to unwrap it. If it doesn't get unwrapped, foreign clients of
the server may not be able to properly use the files (jpegs right?)
because of the wrapping which includes the Mac info.
Or, since this is Mac-to-Mac, maybe there is a "MacBinary" mode (instead
of "binary") that will wrap up ALL the info (including comments) for you,
AND unwrap it on the other side? I think either Fetch or Anarchie (now
Interarchy) had such a mode, and Mac FTP servers understood it, IIRC.
Hope that helps clear up the situation,
-Randy
P.S. NTFS doesn't actually care about the names of the streams (other
than ::$DATA). Services for Macintosh and DAVE are what care about the
names given above. NTFS just maintains them. OLE supposedly also uses
named streams, presumably with its own set of names. I hear not much
else on the PC uses streams, thus the myth that the Mac is alone in using
forks to store files in multiple parts.
##############################################################
# Thursby Software Systems, Inc. #
# #
# Randy Boring Network Engineer #
# 5840 W. Interstate 20 Suite 100 Arlington, Texas 76017 #
# Phone: 817-478-5070 Fax: 817-561-2313 #
# email: [EMAIL PROTECTED] web: www.thursby.com #
# #
##############################################################
