Miklos Szeredi <[EMAIL PROTECTED]> 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).
