> It would be easier if aliases didn't exist. They do. I think the programs
> that actively make use of short names are dosemu, wine, and possibly samba.
> You also cannot create files if a short alias exists, and if there is no
> exposure of the aliases, you just get weird EEXISTS or EPERM type errors
> without being able to access the file. I don't think the thing to do is
> to change the semantics of the filesystem. Linus suggested something to
> simplify things so you won't end up with multiple dentry chains to the same
Yes, multiple chains are evil. I'm not sure that the way suggested
by Linus is the best option here, but what I think is the Right Way (tm)
definitely belongs to 2.3 - layers.
> file. I think that would be a better change than to change the filesystem
> semantics because dealing with dentries and inodes in combination is hard.
> It certainly was easier dealing with these issues when only inodes existed.
>
> > BTW, IMHO changing inode under dentry is evil and unnecessary:
> > we can remove_inode_hash(), change i_ino and then do insert_inode_hash().
> > It's what I did (testing right now) with msdosfs.
>
> Any way you can get it to work is fine with me. Just make sure you
> run through the test suite before you conclude that your changes work.
> Changing the inode under the dentry was the only way I could deal with
> moving open files.
You have races there. Think what will happen if somebody is in the
middle of rename (semaphores held on parents) and another rename moves one
of those parents.
> After a move, the inode refers to something
> different on disk than before the move. It looks like you found a way
> to change the inode by using remove_inode_hash() and insert_inode_hash().
Not exactly. If you'll unroll your code you'll see that you end up
copying almost all fields from old struct inode to the new one. BTW, some
of the fields you don't copy should be copied too - dquot, for one. Now,
things that (a) are not copied and (b) interest somebody outside of
FAT-derived family are i_ino and i_hash. i_hash is calculated by i_ino
(and device). So I propose the following variant: unhash the inode, change
i_ino and put it back to the hash. Since we have the parent locked there
will be no lookups that might be interested in our inode, so temporary
unhashing is OK.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/