fuse 2.9.4 on ubuntu 15.10 exhibits an infinite negative cache about libfuse HOT 7 CLOSED

I cannot reproduce this with FUSE 2.9.3 and sshfs 2.5. There is no error from ls, and the file shows up again after about 10 seconds. Could you try to reproduce with the newest versions? Also, (to simplify things) can you try to reproduce with exampeles/fusexmp_fh as well?

from libfuse.

Hi,

For what it's worth:

local> mkdir empty; cd empty; sshfs localhost:empty /mnt
remote> cd /mnt
remote> touch pan
local> rm pan
remote> touch pan
touch: cannot touch ‘pan’: No such file or directory
remote> ls
remote> touch pan
remote> ls
pan

fuse: kernel api 7.23
debian jessie 8
fuse: 2.9.3
fusermount: 2.9.3
linux 4.4.11
sshfs: 2.5
using FUSE kernel interface version 7.19

from libfuse.

@d-a-v There's no bug in what you've showed. touch may fail with ENOENT even on a local file system without using FUSE. This is because touch needs to issue two different system calls (for creating the file or/and for changing its timestamps), and the file may be deleted (or created) in between those two syscalls. The time window for this race condition is just a lot shorter when there's no sshfs involved (so you're unlikely to see this in practice).

from libfuse.

I understand.
However, even if this is unrelated, this is quite strange that:
sleep 10; touch pan written after the other console's rm returns a 'no such file'. (a sleep 60 instead is ok).
I won't further interfere on this bug :)

from libfuse.

Can't reproduce it using example/fusexmp_fh from libfuse 2.9.7, but issue is still there when I try with libfuse2.9.7+sshfs 2.7

from libfuse.

In other words, this is an sshfs bug. Or am I missing something?

from libfuse.

I'm closing this now, since it seems to be a problem with sshfs rather than libfuse.

from libfuse.