Re: silent semantic changes with reiser4

[Linus Torvalds]

On Thu, 26 Aug 2004, Denis Vlasenko wrote:
> 
> Is it possible to sufficiently hide "dirs inside files"
> so that old tools will be unable to see them?

Certainly possible.

> I just checked:
> 
> ls -d /foo  does lstat64("/foo", ...)
> ls -d /foo/ does lstat64("/foo", ...)
> 	but
> ls -d /foo/. does lstat64("/foo/.", ...)
> 
> Will it work out if "dir inside file" will only be visible when referred as "file/."?

That would likely be the _easiest_ approach for the kernel, and does solve 
the problem with some apps knowingly removing the trailing '/'.

Note that we could try this out with existing filesystems with very 
minimal changes:

 - make directory bind mounts work on top of files ("graft_tree()")
 - make open_namei() and friend _not_ do the mount-point following for the 
   last component if it's a non-directory.
 - probably some trivial fixups I haven't thought about. There might be 
   some places that use "S_ISDIR()" to check for whether something can be 
   looked up, but the main path walking already just checks whether there
   is a ".lookup" operation or not.

This would already allow people to "try out" how different applications 
would react to a file that can show up both as a directory and a file. The 
patch might end up being less than 25 lines or so, the difficulty is in 
finding all the right places.

Al, anything I missed?

(And yes, it's a quick hack, but it's a quick hack that would probably
mimic a good part of what we would have to do internally in the VFS layer
to support this notion anyway).

		Linus
-
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/