pretty sure this line is what's causing tests to fail

but that fixed other things... :(

computers are hard

trust me, this is right.
Maybe it deserves a comment...

not sure about the underlying structure--

• why isn't this happening for all opens?
• how come the same fi *File can be opened by multiple things and set the seek position to different spots.

my impression is that an open call should allocate a handle/descriptor of some sort with its own seek offset.

fuse kinda handles this for us, and now that I think about it, this seek(0) should really just go at the top of the function.

All reads at 'ReadAt' and all writes are 'WriteAt', so you dont have to worry about what offset your file descriptor is at. The seek(0) resets the cache buffer for the ipnsfs file, I should probably just have a Reset method on it instead of doing this.

so it's not threadsafe. right? two simultaneous reads will read at different locations?

Thats the weird part, I've thrown a concurrent reads/writes stress test over this code, with the race detector on, and got nothing.

with the race detector

did you check all the reads got what you expected? interleaved writes could happen, without meaning a golang race.

Thats the weird part

idk, sounds to me like this should have a separate handle per open with its own offest. should ask @tv42

Aall the actual reads and writes really are ReadAt / WriteAt style. Kernel keeps file offsets, doesn't even communicate them through FUSE. You seem to be doing that right.

The real thing you have to worry about is reads and writes happening at the same time. How does your fi.fi there like two Write calls at the same time?

Separate Handles is mostly useful for e.g. keeping track whether the handle was opened O_RDONLY or not, for example if your backing store is cheaper to open read-only than read-write.

The OpenTruncate logic there belongs in Setattr, the kernel will tell you when it wants to change the length of the file.

@tv42 does fuse allow concurrent writes to the same file? or concurrent reads?

oh, yeah. Ipnsfs.File is mutex protected. everything here is fine

@whyrusleeping FUSE in itself has very few real guarantees about what cannot be concurrent. Different Linux versions, OSXFUSE, FreeBSD etc may enforce some of their own mutual exclusions, but I wouldn't rely on that.

Yeah, i realized after asking that I already do all my locking in the ipnsfs.File methods