|
From: Anton A. <ai...@ca...> - 2005-08-24 16:14:04
|
On Wed, 24 Aug 2005, Yuval wrote: > 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. :-( > > > > 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) > > > 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? Depends what you mean by lexicographical. If you mean that their attribute _value_ (not attribute record!) are compared byte by byte and the first difference encountered give you the -1 or +1 result then yes, you are correct. If by lexicographical you mean some "string" comparison then you got it all wrong... (-; > "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? No it cannot. @val to ntfs_attr_lookup() is only valid for always resident attributes. It is forbidden to have more than one attribute with same name and number if it can be non-resident. Also @lowest_vcn is only valid for attributes that can be non-resident. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
