Problem with FUSE + fts

[Hiroshi Nishida]

Thank you for your response.

On 3/25/16 4:53 PM, Rick Macklem wrote:
> I think I see the same thing when doing an "rm -r" on a fuse/GlusterFS volume.

Unfortunately, it happens also with "find XXX -print", though I have 
experienced a similar "rm -r" + "XXX: No such file or directory" problem 
with UFS + SUJ.
And I also verified with truss that in

_fstat(fd, &sb);
p->fts_ino != sb.st_ino

stat() system call is called with the same path as p's.

Anyway, the following patch for lib/libc/gen/fts.c prevents the error 
but is far from a good solution.
https://github.com/scopedog/FUSE-Test/blob/master/fts.c.patch
It assumes that the filesystem id (f_type in struct statfs) of FUSE is 
0xed but I am not sure if it's applicable to all FUSE filesystems.

I'll look into FUSE source code next week.
> To be honest, I just add a "-f" to the command to shut it up and then it deleted
> the tree.
>
> I think, in general, what readdir() returns after an entry is unlink'd is undefined
> behaviour. As such, the safe way to delete all of a directory is something like:
> - in a loop until readdir() returns EOF
>    - opendir()
>    - readdir() the first entry
>    - unlink() that entry
>    - closedir()
> --> So that all you ever do is readdir() the first entry after an opendir().

By the way, could you delete all the files with "-f"?
I am testing with a pretty big directory containing 81,000 files/dirs 
and have never used "-f", but have to "rm -r" again for undeleted entries.
However, the offset problem is very interesting as it seems to be 
applicable to all filesystems.

Thank you.

-- 
Hiroshi Nishida
nishida at asusa.net