Partial rufs-warnings.txt read

[Jille]

$ cat /tmp/rufs-mnt2/Movies/rufs-warnings.txt
*** RUFS encountered some issues showing this directory: ***
failed to readdir on peer quis-t-2375@circle, ignoring: rpc error: code = DeadlineExceeded desc = context deadline exceeded
failed to readdir on peer sjors-pc@circle, ignoring: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp a.b.c.d:12010: connect: no route to host"
failed to readdir on peer sjors@circle, ignoring: rpc error: code = Unaquis@t-x:~/go/src/github.com/sgielen/rufs$

~483 bytes

This really should be impossible, no? fuse.go opens the handle, we get a vfs.fixedContentHandle. We shouldn't be in the business of reopening it.

[sgielen]

I think this could happen if the size of rufs-warnings.txt changes between the readdir/stat and the open. We don't cache the contents of the rufs-warnings.txt (since we generate it clientside, and we only cache contentside responses), so this scenario is possible:

• Readdir is performed; since 2 clients did not respond, rufs-warnings.txt exists
• Stat is performed; since 2 clients did not respond, rufs-warnings.txt is ~300 bytes
• Open is performed and the readdir is retried. Now, cache for one client expired and they did not respond, so there are 3 errors. rufs-warnings.txt is now ~400 bytes so our Handleis a fixedContentHandle with 400 bytes content, but of course, fuse doesn't know that.
• Reads occur to read the first 300 bytes, so 100 bytes are missing.

This can also happen if the error around a client changes (e.g. context deadline exceeded <-> connection timeout).

This could be resolved if FUSE optimistically reads further than Stat size until it receives EOF. Not sure if we have any effect on that, though.

It can also happen the other way around: our Stat says the file is ~400 bytes, but then we open and the file is ~300 bytes, so fuse Read returns EOF before FUSE expects it. This should be handled gracefully though.

I would propose, until further evidence that this is really a bug, to close this as expected/acceptable behavior.