Re: Fw: [POSSIBLE-BUG] telldir() broken on ext3 dir_index'd directories just after the first entry.

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Nov 18, 2004 at 12:22:38PM +0100, Jan Engelhardt wrote:
> >So instead what we need to do is wire '.' and '..' to have hash values
> >of (0,0) and (2,0), respectively, without ignoring other existing
> >dirents with colliding hashes.  (In those cases the programs will
> >break, but they are statistically rare, and there's not much we can do
> >in those cases anyway.)
> 
> IMO it's better to fix the mess all at once to have it weeded out for some
> months.

Programs that assume that '.' and '..' are the first and second
entries of a directory are intrinsically broken; POSIX never
guaranteed this to be the case.  Unfortunately, historically things
have always worked that way, and so there may be some broken programs
lurking out there.  But there's really not much we can do.

Before, we hard-wired '.' and '..' to always be first, at the cost of
breaking programs that used the (broken by design) POSIX
telldir/seekdir interfaces.  Since telldir/seekdir, however badly
designed, are part of POSIX, it seems appropriate to let those
programs work, but the cost is a statistical probability that programs
making assumptions about the order of '.' and '..' will break.  We
don't really have a choice here.  

(Actually, I guess we could define a new hash function that never
produces certain hash values, but that would break compatibility with
all existing deployed filesystems that use ext3 htree.  That's not an
option, either.  So again, making a best effort, but breaking programs
that are fundamentally broken is the best we can do.)

						- Ted