macOS Files extracted from .sit appear ok in Finder but ZERO bytes long in Terminal

[shreddy]

I'm using a font from a .sit (here). Extracting with Stuffit Expander - contents looks ok from Finder.

However if you ls the files from a Terminal shell, they're 0 bytes in size - not what Finder shows at all!

The main problem is that I need to copy the files about with some shell scripts as part of my build process BUT the copied files then become zero bytes for real even when viewed from Finder and are then broken/unusable.

Anyone seen this kind of problem or know of a solution/workaround?! It's driving me nuts!

Thx!

 

[robbieduncan]

Is it possible that all of the size you see in the Finder is in the resource fork? A lot of tools don't deal with that situation well...

 

[shreddy]

Ahh, wasn't familiar with resource forks.. Wikipedia seems quite useful:

Until the advent of Mac OS X v10.4, the standard UNIX command line utilities in Mac OS X (such as cp and mv) did not respect resource forks. To copy files with resource forks, one had to use ditto or CpMac and MvMac.

I think the .sit contents are pretty old, possibly pre-OS X. According to the above though cp/mv should cope, but doesn't - I'm running 10.5 Leopard.

Maybe I can somehow convert the .bmap/.suit font files into a more up-to-date format?

 

[iSee]

Each file might have a companion file to hold the resource fork (I'm guessing they must because Finder is reporting non-zero file sizes). The companion file would start with a . (period), so they are hidden. Use -a with ls to list them.

If so, you can copy the companion files along with the "regular" zero length ones and that should work.

I'm not sure why cp isn't handling it. Maybe because the .sit files are old, they extract the resource forks in a way cp doesn't understand (but Finder apparently does)?

Anyway, see if you can find & copy the companion "dot" files.

 

[Detrius]

I was under the impression that "mv" and "cp" in Leopard ARE resource fork aware. However, as the previous poster pointed out, the resource fork may be in a technically different file. (The names start with "._" however.)

"CpMac" and "MvMac" have been a part of the developer tools to get around the problem of "mv" and "cp" not respecting resource forks, but as stated in the CpMac(1):

As of Mac OS X 10.4, the cp command preserves metadata and resource forks of files on Extended HFS vol-
umes, so it can be used in place of CpMac. The /usr/bin/CpMac command will be deprecated in future
versions of Mac OS X.