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: DavidRavenMoon on Nov 26, '03 03:23:19PM

Resource forks are quite handy, and in fact I'm sad to see them go in OS X.

Some examples. On a PC, or even with data only files in OS X, the file's suffix is the only thing that tells the OS what type of file it is, and what to use to open it. That's fine and dandy for the majority of situations, but I'll give a few examples.

Let's take the EPS (Encapsulated PostScript) file format. I'm a graphic artist, and two of the programs I use all day are Adobe Photoshop and Illustrator. Both of these applications can save a file in the EPS format, but the files are quite different! Illustrator EPS files are mostly vector information, and opening one of these in Photoshop will cause the file to be rasterized. Photoshop can also save EPS files, but these are basically bitmap raster files wrapped up in a PostScript shell. If you open these in Illustrator, you will see a document with a placed image.

If these files had no resource fork, such as when they come from a PC, you have no idea what application created them, you only see "myfile.eps." On a Mac, you can clearly see which icon each has (Photoshop or Illustrator), and each has Type and Creator code meta data embedded in the resource fork, which is how the icons are assigned. Previews and thumbnails are also in the resource fork.

This way, double clicking on the file would launch the correct application, even if you have OS X set to use Preview by default for EPS files.

So if you know you are going to send a file to a PC user (or any OS other than Mac OS) saving your image files with no previews will prevent resource files from being sent with the data file. Some Mac files, such as font suitcases, will become damaged with the resource stripped off, since the actual font is in the resource fork. OS X's dfonts are data only. If a file with resource forks needs to be sent it must be stuffed and not zipped (unless you are doing this trick, but I think it's much easier to use Stuffit).



[ Reply to This | # ]
Resource forks are not the only way to tell the file type!
Authored by: hopthrisC on Nov 26, '03 04:18:48PM
I don't want to start a huge discussion here! I myself tend to ignore the whole resource fork business, hoping that one day the issue will go away one way or the other, but...

You can tell the file type (very often) from the contents of a file. In fact there is a Unix command to do this: file(1). Try it on a .psd! To verify that it does not need the suffix or the resource fork, cp the file on the command line and run file again:

aschenputtel:~ hop$ file test.xxx
test.xxx: Adobe Photoshop Image

Let's take the EPS file format ;) Every PostScript file has to start with "%!PS". Easy to tell the type of content from this.

As for the Photoshop vs. Illustrator example you brought up: That's a valid point in some respects, but you may also see it from another standpoint: I usually open files with the application that is best fit to the task I intend to perform, which is not necessarily the same as the one used to create the file.

Once the file is saved as .eps in Photoshop, you can't vectorize it anyway, and Photoshop won't let you edit vector data, no matter how often it was created in Illustrator. [ignoring the fact that paths are vector data, just to get my point across ;) ]

The only reason to save a picture as EPS from Photoshop probably is, that you want to import it in a vector based application that doesn't import other formats (LaTeX comes to mind), so will you double click it ever again to open it with Photoshop?

The fonts... what should I say? Have you noticed that Apple is moving away from PS fonts and to TrueType fonts?

[ Reply to This | # ]
file type info is not usually in the resource fork
Authored by: hayne on Nov 26, '03 05:05:14PM

Just to clarify:
The file type and creator info (that tells the Mac what application to use to open this file) is not usually stored in the resource fork. This information is stored in HFS+ as part of the "catalog" along with other metadata like the time of last modification, etc.

To prove this to yourself, take a file that has type/creator information - e.g. a file created by a Mac application, not one downloaded from elsewhere. Make a duplicate of the file in Finder and rename the file so it is named "junk", then open a Terminal window and then do the following commands:

ls -l junk/..namedfork/rsrc
cp /dev/null junk/..namedfork/rsrc

The first of the above commands shows you the resource fork of the file named "junk". If there is no resource fork, it will show up as zero size.

The second of the above commands will remove the resource fork of the file named "junk".

In spite of the resource fork being removed, you should still be able to open the file as usual by double-clicking on it in Finder.



[ Reply to This | # ]
Easily create HFS-aware PKZIP and unix archives
Authored by: gshenaut on Nov 26, '03 09:27:23PM

EPS is not a good example since EPS files contain a %%Creator header line
that identifies the program that created it, which is just one example of how
the material placed into resource forks can be handled painlessly without
them.

Greg Shenaut



[ Reply to This | # ]
Creator and Type codes have NOTHING to do with rsrc fork
Authored by: elmimmo on Nov 27, '03 03:18:29AM

At the risk of sounding repetitive, even though some people are glad to have creator and type codes for files, they have NOTHING to do with resource forks. It is a file attribute stored in the HFS+ file catalog, something like the creation date.



[ Reply to This | # ]
Creator and Type codes have NOTHING to do with rsrc fork
Authored by: gshenaut on Nov 27, '03 11:32:38AM

OK, so what good are resource forks?



[ Reply to This | # ]