On Wed, 8 Nov 2017 16:50:07 +0100 Martin Pieuchot <m...@openbsd.org> wrote:
> On 08/11/17(Wed) 14:12, Helg Bredow wrote: > > There is a bug when creating a file in fuse-exfat and then deleting it > > again without first unmounting the file system. The reason for this is > > that fuse-exfat maintains strict reference counts and fuse currently > > calls the file system create and open functions when it should only > > call create. > > [...] > > Does it call the userland file system functions because it receives 2 > FBT messages? Yes, fuse receives both create and open from the kernel and blindly passes them via FBT messages to userland. > > Can you see which FBT messages are generated by the kernel? Does > ktrace(1) has support for that? The debug output from libfuse let's you trace the FBT messages and I also have judicious printf() statements to help me diagnose. > > > The VOP_CREATE(9) function does not behave like this so we either need > > to simulate it within fuse or fall back to mknod() and open(). > > VOP_CREATE(9) is just a wrapper around the underlying FS. In your case > fusefs_create(). This function enqueues a single FBT_CREATE operation, > so it doesn't match what you said before. > > So I still don't understand the problem. Where is the bug? > The problem is that the kernel's idea of create is different to the fuse FBT_CREATE passed to userland. The kernel doesn't expect create to also open the file. fuse create was designed to map 1:1 to atomic_open, which OpenBSD does not have and I'm not keen to implement it. > If the problem is that the kernel enqueue 2 FBT operations instead of > one, then change the kernel. > > If the problem is that fusefs_create() does not have all the information > for generating a FBT_CREATE message and that it hardcodes (O_CREAT|O_RDWR) > then maybe you should delay that operation to fusefs_open(). > > These are stupid guesses because I don't understand what the problem is. Your last suggestion is one that I had not considered. I immediately went to implement it but was disappointed to find that it won't work without crazy lock management and maintaining state between kernel calls. I think it's too complex and prefer the simple solution I've proposed because it behaves the same as ffs, nfs etc. -- Helg <xx...@msn.com>
