HFS Plus resource/data forks

Does the following help?

"On Apple disks, HFS+, files often contain both data and resource forks. There is also an important part of Metadata stored in the directory that indicates the application that should open the file. PCs tend to work just on file extensions, but Macs have a 'hidden parameter to assist, and so the file name is not actually important. On OS X, there is a method of sharing this information on a standard PC disk. The method is called AppleDouble format. Put simply, for every file there is an associated file with the same name, but prefixed ._ For example for fred.doc there will also be a hidden file ._fred.doc This extra file will be at least 82 bytes long, and longer if there is an associated resource fork. By using these files, the Mac on OS X can treat a FAT disk in the same way it handles a native HFS+ disk, and no information is lost."

What about a Windows application reading the same file, would it simply ignore ._fred.doc and only read the contents of fred.doc? What if you were to send the file over a network, for instance as an email attachment or file share - would the resource fork simply be left behind or would it be integrated into the file in some way?

Typically a PC can ignore the resource fork.

Problems can arise that if a Mac file is sent called 'fred', the PC user has to work out that it is a .DOC, .XLSX, JPEG etc

ie PCs and Apples are different

while it explains how to find both forks, there's no information on how to equate that to the simpler filesystem storage methods.

There's no reason to find it there. That's a compatibility or interoperability question, and so not really a question for the file system to solve. Look for the information in that kind of tool or specification.

For example, if one were to copy a file containing both a resource and data fork from HFS Plus to a FAT32 volume, how would the contents be reassembled?

Can it be 'reassembled'? Depends on what tool you use.

For example, if there is such a thing as a Samba server or FTP server for Apple, it will make a decision about how data fork and resource fork are presented to the client. Or tools like ZIP or ARC – what do they do? Or, what does PC tools do with StuffIt archives or other Apple archiver files? Or, if you have a Apple tool that writes to FAT file systems, what does it do? or a PC tool that reads HFS? Or ISO-9660 burning software? Or, what does a tool like ISOBuster do when it extracts files from an Apple HFS CD?

There's no single answer, as far as I know.

Or turn the question upside down – how does Apple tools 'de-assemble' files from FAT32 sources into resource and data forks respectively.

Coming back to this topic with a greater understanding, I'm now trying to figure out the following

1. Definition. The publicly available specification does not fully define extended attributes. Is there a more complete definition elsewhere that I haven't found?
2. File hashes. Are there conventions on what data gets read into the digest in forensic applications (is it just the data fork)?
3. Exporting. If you wanted to export a file with extended attributes, would you care about the resource fork or only the data (assume that you can view the contents of the attributes in <forensic application of preference>)?

"For example, if one were to copy a file containing both a resource and data fork from HFS Plus to a FAT32 volume, how would the contents be reassembled? "

This should be easy enough to test. However, I did find a couple of sources that might help understand the associated "._" files.

http//lists.apple.com/archives/applescript-users/2006/Jun/msg00180.html

and Amit Singh's text "Mac OS X Internals A System's Approach.

It appears that OS X provides support for other file systems in part by placing data/meta-data in these special files. The special files are supposedly when the file system being written too doesn't support all the data/meta-data. This was more common in HFS and less common in HFS+.

I will test this as well and circle back.

Scott