• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Resource Fork as Extended Attributes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Resource Fork as Extended Attributes
      • From: Chris Suter <email@hidden>
References: 
 >Resource Fork as Extended Attributes (From: shailesh jain <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: Anton Altaparmakov <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: shailesh jain <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: shailesh jain <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: Mark Day <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: shailesh jain <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: Mark Day <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: shailesh jain <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: Mark Day <email@hidden>)
 >Re: Resource Fork as Extended Attributes (From: Chris Suter <email@hidden>)

  • Prev by Date: Re: Resource Fork as Extended Attributes
  • Next by Date: Re: Resource Fork as Extended Attributes
  • Previous by thread: Re: Resource Fork as Extended Attributes
  • Next by thread: Re: Resource Fork as Extended Attributes
  • Index(es):
    • Date
    • Thread