On Thu, Mar 22, 2012 at 01:37:04AM +0400, Evgeniy Polyakov wrote: > On Wed, Mar 21, 2012 at 09:18:35PM +0000, Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote: > > I think I've asked that question at least 3 times. Never got anything > > resembling an answer... Is that misspelled dentry_path()? Or is something > > subtle going on and we really want different strings generated for > > chrooted processes here? > > This is a special case which does bad things intentionally. > http-compatibility was added in _this_ POHMELFS on demand from people > who do want to access files by handle created from whole path. Not name > or inode number, but whole path, since that's only what is available in > http (or more generally via rest api) > > It is limited, wrong and error-prone. It does not even support rename > and hardlinks. But that's what people want. > When I bind-remount part of the tree, things 'dissapear' from the tree. > Yes, this is really an uglymoron, but it was created for _some_ limited > case which rougly work in sandboxed environment only. IDGI. Again, you are getting different strings for different processes, so that one inside a chroot generates shorter pathnames. I'm not asking about races with rename() et.al. - it's obviously racy, but that's a separate problem. Details, please - as far as I can tell, that code looks like a reimplementation of dentry_path() in a curiously broken way; what demands that particular breakage? Again, the question of pathname stability, uniqueness, etc. is a separate story; why this specific weirdness? Note that you are passing a to d_path() a vfsmount/dentry pair that violates all kinds of assertions - dentry->d_sb != mnt->mnt_sb more often than not, to start with. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
