|
From: Yuval <yu...@gm...> - 2005-08-24 15:45:17
|
On 8/24/05, Yura Pakhuchiy wrote: > I had not knew about this when wrote attribute resize (as I already said > our docs is incorrect in this part). Have to rewrite some parts. :-( >=20 > Anyone please update our docs, something like this: I guess I'm that "Anyone" ;-) Can you point me exactly to the page(s)? (Your initial post suggested there is more than one) =20 > Collation rule for attributes: > 1. Type. > 2. Name. > 3. Lowest VCN (for attributes that can become non-resident) / > Attribute value (for always resident attributes). Do I understand it correct: Let attr1 and attr2 both be unnamed 0x30 resident attributes, so their collation order is a lexicographical one? "for attributes that _can_ become non-resident": Assume attr1 is resident, but allowed to be unresident, and attr2 is unresident. Which one comes first? Can this scenario even happen? > Inode can have several attributes with same name and type if they are > always resident. But attributes that can become non-resident should > always have unique pair of type and name. Thanks -- Yuval |
