bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [bug #17877] Invalid "No such file or directory" error on files


From: Jim Meyering
Subject: Re: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Thu, 05 Oct 2006 13:44:11 +0200

Miklos Szeredi <address@hidden> wrote:

...
>> Are you saying that with your FUSE patch, the above is to be expected?
>> Meaning, the inode numbers are expected to differ, even if nothing
>> happens to "/mnt/fuse/tmp/test" during the "..." period?
>
> No, what I'm saying that some filesystem cannot _guarantee_ that the
> inode number will not change between two operations, unless an open
> file descriptor or a cwd is refering to the inode.

Nonetheless, with your patch (and without it, but less frequently), a file
may have one inode number at one point, and then, that same underlying
file (i.e., not renamed/replaced) can have a different inode number.

That is a convincing argument for why we should avoid using those file
systems, when reliability is important, i.e., almost always.

...
>> The point is that it is important for any file system to provide
>> the same device and inode numbers upon repeated accesses to the
>> same logical file system object, unless that object has been e.g.,
>> removed or moved aside and then replaced.
>>
>> If your patch makes a FUSE-based file system violate such a
>> fundamental assumption, then I think problems are inevitable.
>
> My test filesystem makes it easy to reproduce problems which are
> otherwise much harder to reproduce.  It doesn't change anything about
> the assumptions the application can make about these "inodeless"
> filesystems.

Thanks for explaining.

I suspect that it is possible, and maybe even feasible, to work around
this violation of fundamental assumptions in some limited cases.
However, in general, I think it's not possible, or at least not
worth the effort.

In spite of that, I have thought about changing fts to be usable even
in the unusual event that these inode-less file systems misbehave.
However, ignoring all dev/inode-based tests would raise other issues:

  - there would be no protection against the attacks I already mentioned
  But a work-around is possible: rather than hard-coding the failure,
  provide a callback, and let the caller determine how to handle it.
  However, this is a lame hack: on an affected file system, there would
  be no way to distinguish between an attack and a directory inode number
  that changed due to a flushed cache.
  IMHO, disabling such a safety net is a very bad idea.

  - directory cycle detection would be unreliable, which applies to
  symlink loops as well as hard-link (file system corruption) loops.

  - this would be a device(file system)-specific attribute, yet a
  directory traversal can span many devices.  Do we really want fts
  to be calling statfs (like "stat -f --format %T ." does) every time
  it transitions from one file system type to another (new one)?
  Then, it'd turn work-arounds on and off depending.

All of the above sounds like it'd be invasive, yet provide little benefit:
mere half-measures to work around low-probability events affecting
only unreliable-by-definition, non-POSIX file systems.

Are you still convinced it's worthwhile?
If so, would you please build coreutils-6.3

  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.3.tar.gz
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.3.tar.bz2

and run its tests ("make check") from a build directory in your
modified file system?  It might be useful to know the scope of the
problem.  For example, do tests of cp/mv and ls fail?  Maybe not,
because they use a different approach (that has limitations).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]