Re: silent semantic changes with reiser4

[Jamie Lokier]

Christoph Hellwig wrote:
> > >    - O_DIRECTORY opens succeed on all files on reiser4.  Besides breaking
> > >      .htaccess handling in apache and glibc compilation this also renders
> > >      this flag entirely useless and opens up the races it tries to
> > >      prevent against cmpletely useless
> > 
> > So `find -type d' would list every file on the system?
> 
> the find I have here is using lstat and not open with O_DIRECTORY, so
> no.

The find-like program I use (called treescan) uses O_DIRECTORY as an
optimisation.  It assumes that O_DIRECTORY will only open objects
which are directories and can be read using readdir().

However, if reiser4 returns d_type values, then it won't even attempt
an open on non-DT_DIR objects, and that's a better optimisation.
(reiserfs doesn't return d_type values, unfortunately).

So the list of files that treescan finds depends on whether reiser4
implements d_type.

This is nothing like a POSIX filesystem.  You untar a tree, and then
listing it recursively shows extra things created by reiser4.

I quite like the principle, but because it's not like POSIX and
doesn't match some program's expectations, it's a problem in its
present form.

xattrs aren't a complete solution as you can't store structured data
in an xattr.  For example, with reiser4's model, you can cd into a
.tar, .zip, .mp3 or .xml file and list the internal structure along
with the file's metadata.  You can't do that with xattrs.

Programs exist which quite reasonably assume that when you create a
file, you can't opendir() the file, and recursive listings (like find,
ls -R et al.) won't automatically traverse into every file.

On the other hand, being able to enter a file in a directory-like way
allows structured representations of the contents to be accessed in
the very useful "everything's a file" way -- i.e. ordinary tools.

So here's a semantic proposal:

   1. O_DIRECTORY won't open an ordinary file.
      Corollary: opendir("file") won't open an ordinary file.

   2. An ordinary file path followed by "/" won't open an ordinary file.
      Corollary: opendir("file/") won't open an ordinary file.

      This is because appending a trailing slash is an alternate
      way for userspace to get the same results as O_DIRECTORY.

   3. An ordinary file path followed by "/" _and_ one or more path
      components will open the file as a directory and enter it.
      Corollary: opendir("file/.") will open an ordinary file.

   4. The type of "file/." shall be S_IFDIR, _not_ S_IFREG.
      Corollary: stat("file/.") will return that it's a directory.

      The intention here is that explicit requests to examine the
      metadata or alternate structure representations of a file will
      create such a view, but the view is only available if requested
      explicitly.

      When such a view is created, the results of stat(), O_DIRECTORY
      and opendir() are absolutely consistent.  This will minimise
      confusion.  Programs which recurse over a directory tree won't
      look inside any of the files.  However they can be explicitly
      asked to recurse starting from a path inside a file: then
      they'll recurse over a single file's metadata and structured data.

Regarding the problems of safe locking in the VFS.  The VFS assumes
that directories are not hard linked: i.e. that they cannot appear at
more than one path in a filesystem.  Files-as-directories breaks that.

However, VFS does support directories on multiple paths, using bind mounts.

So it wouldn't be out of the question if entering a file (as described
above) effectively auto-mounted a bind mount at that point.


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