MD5 identical for font files

Question

I put together a script that uses openssl sha1 <file> to check for duplicate files in a folder hierarchy.
It gives the same hash result for all the members of a font family. Does that make sense as I would have thought there would be some differences between the Suitcase and Postscript files.

Answer 1

MarkDouma® wrote:
Are these font files resource fork-based, or data fork-based? Traditional Mac font suitcases and PostScript Type 1 outline fonts are resource fork based files. Most of the command line tools only recognize the data fork of files, and will regard a resource fork-based file like a font suitcase as empty. The hash you're getting back will most likely be the hash you'd get for an empty file (for example, if you created a test file using "touch ~/Desktop/testFile").
That appears to be exactly the case. I tested md5 and +openssl sha1+ on a couple of fonts I've have for aeons. I get the same hash as if I create an empty file with touch.
This "..namedfork" method worked in OS X 10.4.x and prior, but as far as I remember, they removed support for that way of accessing files from OS X 10.5.
You can get to the resource fork on Leopard by appending /rsrc:
$ ls -l Aquil
-rwxrwxrwx@ 1 username staff 0 Sep 9 1998 Aquil
$ ls -l Aquil/rsrc
-rwxrwxrwx 1 username staff 156440 Sep 9 1998 Aquil/rsrc
$ touch test.txt
$ md5 -q test.txt
d41d8cd98f00b204e9800998ecf8427e
$ md5 -q Aquil
d41d8cd98f00b204e9800998ecf8427e
$ md5 -q Aquil/rsrc
b872478171cb1fd9838c7ecef926c89b
So a script would probably need some kind of logic where it looks for zero-length files, then checks to see if there's a resource fork. If there is, then get the hash of that instead...
charlie