On Oct 22, 2007, at 1:26 AM, Martin Costabel wrote:
Jordan K. Hubbard wrote:
On Oct 21, 2007, at 2:45 PM, Tim Jones wrote:
Does anyone have details on what functionality should be placed into a BSD-layer app to properly handle resource forks moving forward? We originally considered the copyfile.h hacks, but were warned away by an Apple tech at the last WWDC as there would be a better solution available. What is that better solution?
[]
To anticipate the follow-up question: If you link with copyfile(3) on Leopard and try to run the resulting binary on Tiger, the results are somewhat undefined. A number of improvements were made in Leopard in the process of promoting it to API and while simple usage cases will probably work in both OS versions, there are really no guarantees - it's officially supported only in Leopard and later releases.
Are you really saying that there does not exist any method for handling resource forks that will work on both Tiger and Leopard?
I am not saying that. I am saying that the copyfile(3) API, which makes the whole issue far more
convenient, does not work on both. If you are willing to walk the POSIX EA namespace ({get,set}xattr(3)) yourself, the resource fork data is mirrored into that space on both Tiger and Leopard. Similarly, the ditto(1) command has dealt with resource forks since, well, forever.
