On Tue, 2009-02-10 at 15:47 +0100, Robert Millan wrote: > On Tue, Feb 10, 2009 at 10:54:55AM +0100, Michel Dänzer wrote: > > > > Michel may know better, but I think it's the order of characters. > > > Those with the lower order go first in the sorted binary tree. Those > > > with the same order are equivalent on the filesystem level. That is, > > > "foo" can only be between "bar" and "quux" in the node tree. "foo" > > > and "Foo" are the same tree node and thus the same file. > > > > I think that's a nice summary, thanks. > > Ok. There's a pair of things that need to be cleaned up though. If I > understand correctly, the definition of caseorder[i] is such that given too > distinct values of i, it can be used to sort them (if this is so, I think > it should be explicitly mentioned in the comment).
Yes, for a given filename character value i, caseorder[i] is the corresponding B-tree sort order. > So if the table is basicaly storing values that enumerate something, why are > we using hex to represent them? Hex gives the impression they're an opaque > sort of thing, like code, bitmasks or magic numbers. Your guess is as good as mine. > The reference to "the Macintosh" is a bit confusing, it usually means a > computer, or an OS. I assume it refers to HFS? Yes. I think HFS used to be 'the Macintosh filesystem' before OS X. > We'd also need to know what are these "'casefold' and 'order' tables from > ARDI's code", and what exactly means this is a "composition" of them. Your guess is as good as mine. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel