Re: Resource Fork as Extended Attributes
Re: Resource Fork as Extended Attributes
- Subject: Re: Resource Fork as Extended Attributes
- From: Mark Day <email@hidden>
- Date: Thu, 23 Jul 2009 17:07:06 -0700
Chris,
On Jul 23, 2009, at 4:46 PM, Chris Suter wrote:
Hmm. The code for newfs_hfs looks like it could do with improving too
(at least in the version I'm looking at): it takes parameters to
control the attribute node size yet doesn't do anything with them; it
doesn't create the attributes file. In fact on the version I'm using
it crashes if you try and use it. <rdar://problem/7088315>
There's also an issue with the Kernel where it assumes the B-Tree node
size is 8192 when calculating the maximum size of an inline extended
attribute, when in theory, it could be different. Not likely, of
course, but you'd want to check there's no panics because of it.
<rdar://problem/7088321>
Thanks for the bug reports! We'll have to look into them...
Well, newfs_hfs is supposed to be honoring those values. And in
SnowLeopard, it should be creating an Attributes B-tree by default,
but you can avoid creating one by using "newfs_hfs -c a=0".
The kernel should support any Attributes B-tree node size of 4, 8, 16
or 32 KiB. If it doesn't, that's a bug in the kernel. Using a node
size of 4 KiB will result in the maximum EA size being well under 2
KiB, which is likely to violate the (unwise) assumptions of some
applications.
-Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden