Re: silent semantic changes with reiser4

[Herbert Poetzl]

On Thu, Aug 26, 2004 at 11:55:07AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 26 Aug 2004, Rik van Riel wrote:
> > 
> > So you'd have both a file and a directory that just happen
> > to have the same name ?  How would this work in the dcache?
> 
> There would be only one entry in the dcache. The lookup will select 
> whether it opens the file or the directory based on O_DIRECTORY (and 
> usage, of course - if it's in the middle of a path, it obviously needs to 
> be opened as a directory regardless).

hmm, that might be interesting for applications
like apache which allow to append arguments by
'building' a 'virtual' path ...

http://www.kernel.org/list.cgi/some/more/args

where the web server actually decides where the
script ends and the arguments start by checking
the filesystem ...

> That's not the problem. The problem from a dcache standpoint ends up being 
> when the file has a link, and you have two paths to the same sub-file 
> through two different ways:
> 
> 	.. create file 'x' with named stream 'y' ...
> 	ln x z
> 	ls -l x/y z/y	/* it's the same attribute!! */
> 
> but this is actually exactly the same thing that we already have with 
> mounts, ie it is equivalent (from a dentry standpoint) to
> 
> 	.. create directory 'x' with file 'y' ..
> 	mkdir z
> 	mount --bind x z
> 	ls -l x/y z/y	/* It's the same file!! */
> 
> so none of this is really anything "new" from a dcache standpoint.
> 
> Except for all the details, of course ;)

if the file is removed, but some attributes are
'locked' by access, will the 'other' attributes
remain visible or disappear ... leaving a partial
'view' of the contents? or did I get the idea
completely wrong?

TIA,
Herbert

> 		Linus
> -
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/