Re: [take 3] pohmelfs: call for inclusion

[Al Viro <viro@ZenIV.linux.org.uk>]

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@ZenIV.linux.org.uk) 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.