Re: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

[Jim Meyering]

[I'm moving the discussion to the bug-gnulib mailing list,
 since this concerns the gnulib fts module.  ]

"James Youngman" <address@hidden> wrote:
> For your info.

Hi James,

Thanks for forwarding that.
I confess I hadn't looked at the original bug report.
Just did, and see that it's a different problem than I first thought.
I now see that this is about the dev/ino check when traversing "up"
to return to a previously visited directory.

I find it hard to believe that a commonly used file system implementation
fails to preserve the dev/ino of a component of some process's working
directory.  IMHO, even when it's been unlinked, such a directory cannot
be considered "unreferenced" when a process is still using it.

Miklos, you wrote this:

    There are several Linux filesystems (including smbfs, fat,
    and some FUSE based ones) which cannot provide stable inode
    numbers for unreferenced files or directories.

In the above, context, I don't know what you mean by "unreferenced
files or directories."  Can you clarify?  FYI, as far as fts is
concerned, dev/ino numbers matter for directories, not non-directories.

Can you provide instructions by which to reproduce the failure
you've witnessed?

> ---------- Forwarded message ----------
> From: Miklos Szeredi <address@hidden>
> Date: Oct 4, 2006 10:49 AM
> Subject: Re: [bug #17877] Invalid "No such file or directory" error on
> filesystem without stable inode numbers
> To: address@hidden
>
>> > Follow-up Comment #8, bug #17877 (project findutils):
>> >
>> > Thanks for the patch.  I've tested it and it doesn't seem to make any
>> > difference.
>>
>> Are you using the fts version of find 4.3.x?
>
> Yes, find/find from 4.3.1+patch.
>
> With find/oldfind the bug doesn't show up.

The resulting down side is that the old version of find is
susceptible to a nasty type of attack when traversing a directory
that is writable by another user.