lkml.org 
[lkml]   [2012]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [take 3] pohmelfs: call for inclusion
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.


\
 
 \ /
  Last update: 2012-03-21 22:57    [W:0.030 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site