Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Easily create HFS-aware PKZIP and unix archives' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Easily create HFS-aware PKZIP and unix archives
Authored by: greed on Nov 26, '03 03:22:19PM

Resource forks on data files are typically used to contain 'state' information. For example, a text editor I used to use would write the current position to the resource fork, so any program that didn't know how to use that resource would just see an ordinary text file in the data fork.

Another thing that gets put in the resource fork is the 'preview' and the 'icon' images. This way, a file can have a custom icon, and you don't have to have a separate file. (Anyone remember .info files on the Amiga?)

I believe the TYPE and CREATOR information is handled in much the same way as the resource forks when dealing with non-HFS-aware programs. On HFS, they are actually attributes of the file, just like creation and modification time, size, and so on.

So forks just give you a way of keeping related 'files' together under one name. It is pretty sloppy on Apple's part to leave the standard BSD utilities unmodified; it would at least be nice if the standard 'ls' command could show type and creator as well. (I despise file extensions for type information, I really liked the MacOS way of making it a full-fledged attribute on the file.)

How do you get a custom icon for something on Windows? For executables and DLLs, it seems they use a special section in the COFF file. Can you even have a custom icon on a data file? It would have to be in a separate file if it was.

That's on data files. For program files, resources would contain everything from the icon sets, to the window and menu definitions, sound samples, and so on. Those are now handled with the ".app" directory format.

Generally, on data files, you should always be able to toss the resource fork without damaging the data (as long as you can get the TYPE some other way.) Mail.app sending the resource fork is just dumb, I had to go through and remove all the resource forks before e-mailing some attachments. Given all the "be more like Windows" changes in OS X, many of which are frustrating (file extensions... yuck), why didn't they suppress the resource fork by default?



[ Reply to This | # ]