In article <p05200f3cba67470bba32@[192.168.254.205]>,
 [EMAIL PROTECTED] (Rich Morin) wrote:

> Actually, it may well be a moot point.  Not that many files are
> sparse, so the number of bytes is a reasonable indication of the
> number of blocks.  It's just that I'd rather have the individual
> block count for each fork.
> 
> BTW, I'd be happy to see a bit more information about ..namedfork.
> Google only found a few references, including "Inside Mac OS X:
> Performance", which says:
> 
>    Although Apple recommends moving resources into data files in the
>    application package Resources directory, it is possible to access
>    the resource fork of a file on an HFS Plus volume by adding the
>    suffix:/..namedfork/rsrc to the end of the file pathname.  Because
>    this doesn't work on other file systems, notably UFS, and because
>    it requires you to parse the resource fork structure directly,
>    this technique is not recommended.

Nat notes in reply to me, in message 
http:[EMAIL PROTECTED]/msg04257.html :
 
>From /usr/include/sys/paths.h:
>
>  * Provides support for system wide forks */
>  #define _PATH_FORKSPECIFIER    "/..namedfork/"
>  #define _PATH_DATANAME         "data"
>  #define _PATH_RSRCNAME         "rsrc"
>  #define _PATH_RSRCFORKSPEC     "/..namedfork/rsrc"

Not much else to it, really.


> My interest is that I'd like to think about storing metadata with
> files.  I think I need to take a closer look at the relevant modules.
> I knew Chris had been porting some of Matthias's MacPerl libraries
> over to OSX; looks like I may get a chance to use some of them...

Just be sure to read the README and POD in Carbon.pm for some background and 
other implementation info, as well as bugs etc.  It's not exactly the same.

In re: what Apple said about resources in data forks, I just got a bug 
report the other day about the fact that right now Mac::Resources can't 
handle resources in a data fork; while this isn't technically a bug (I think 
...), it is something I wished it could do already, just in testing, so I 
want to come back to that at some point.

-- 
Chris Nandor                      [EMAIL PROTECTED]    http://pudge.net/
Open Source Development Network    [EMAIL PROTECTED]     http://osdn.com/

Reply via email to