Re: moving affs + RDB partition support to staging?

[Al Viro]

On Sun, May 06, 2018 at 10:32:47PM +0100, Al Viro wrote:
> On Sun, May 06, 2018 at 09:46:23PM +0100, Al Viro wrote:
> 
> > 	I'm fixing that pile of crap (along with the NFS exports
> > one and, hopefully, rename mess as well).  HOWEVER, I am not going
> > to take over the damn thing - David has violated the 11th
> > commandment (Thou Shalt Never Volunteer), so he gets to joy of
> > learning that codebase and taking care of it from now on.
> 
> 	Same scenario on link(2) ends up with
> * ST_LINKFILE created, inserted into the link chain and left around,
> without being present in any hash chain
> * target becoming positive hashed dentry, as if link(2) has succeeded,
> so dcache lookups will be finding it (for a while)
> * unlink(2) on source will have very interesting effects, what with
> the attempts to move ST_FILE entry into the directory presumed to
> contain ST_LINKFILE one, removing ST_LINKFILE from it at the same time.

Oh, lovely...  Looks like that thing wants the hash chains sorted by
block number.  affs_insert_hash() doesn't give a toss - it always
adds to the very end of chain.

Maintaining that requirement (and I can understand the rationale -
they don't want too many back-and-forth seeks on directory lookups)
is going to be great fun on rename(), especially for the case when
the target of rename happens to be a primary name for a file with
additional hardlinks.

I think I see how to deal with that sanely, but... ouch.

Incidentally, we'd better verify that hash chains are not looped - as it
is, there's no checks whatsoever, and it *will* happily loop if you
feed it an image with such braindamage.  I really hope that no fan of
desktop experience has set the things up for e.g. USB sticks with
that on them being recognized and automounted on insertion...