Bad length passed to client process in write operation

[edouardklein]

Hi,

I use a client (9pfuse from plan9port) that communicate with OSXfuse through a file descriptor. When doing a read on this file descriptor, this client expects the first 4 bytes to be an int whose value is the number of bytes read by the read operation (i.e. the return value of read).

This condition is not true when I create a new file on the file system, for example through the command :
echo Hello > /tmp/mntp/NewFile.txt

The value of the int is the length of the header (64), but what is read is the header plus the data (here 64+6 bytes).

I have a very, very ugly fix : adding the following at line 369 of fuse_device.c in kext :
(((struct fuse_in_header*)ftick->tk_ms_fiov.base)->len) = (__u32)(ftick->tk_ms_fiov.len) + (__u32)(ftick->tk_ms_bufsize);

With this, the specific client I use no longer crashes, but I think it breaks other things and it is not a proper fix.

Maybe the client is wrong, and FUSE behave correctly, I did not find the FUSE specifications. If anybody could point me to it, it woud be nice.

If this is indeed a problem, then I hope somebody more knowledgeable than me will be able to fix it.

[bfleischer]

Thanks for your bug report, Edouard. You are absolutely right, we need to take the size of the write buffer into account. The fix will be in the next OSXFUSE release.

[bfleischer]

This should do it osxfuse/kext@091fe79

[edouardklein]

Thank you for having written the correct fix !

Le 08/05/12 05:42, Benjamin Fleischer a écrit :

This should do it osxfuse/kext@091fe79

---

Reply to this email directly or view it on GitHub:
#28 (comment)