wireguard-openbsd/lib/libfuse/fuse_ops.c, branch jd/queueboosts WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/lib/libfuse/fuse_ops.c?h=jd%2Fqueueboosts 2018-07-16T13:10:53Z Implement FBT_FSYNC, which is called on fsync(2) and fdatasync(2). 2018-07-16T13:10:53Z helg helg@openbsd.org 2018-07-16T13:10:53Z urn:sha1:0d64465817bc318c59b559b5ca4ecc8c74468463 Currently ignores the a_waitfor argument and always invokes the file system's fsync implementation synchronously. ok mpi@ Minor cleanup in ifuse_ops_setattr. 2018-06-08T23:43:40Z helg helg@openbsd.org 2018-06-08T23:43:40Z urn:sha1:2670c02ee22148cf5a85ff1d2c38073c0fefeb54 ok mpi@ Implement support for libfuse use_ino option. This returns the file 2018-05-22T12:52:14Z helg helg@openbsd.org 2018-05-22T12:52:14Z urn:sha1:dae5ffec5618b0b660e9064e3b0991bb4ab1b1e8 system's ino for VOP_GETATTR(9) and VOP_READDIR(9) rather than the internally generated fuse ino. ok mpi@ Reformat debug output to one line per opcode to make it easier to 2018-05-21T11:47:46Z helg helg@openbsd.org 2018-05-21T11:47:46Z urn:sha1:1f45a5ac459c17828f22da95377cdfac59fa2334 interpret. ok mpi@ Implement FBT_FLUSH. This is sent whenever a file descriptor is closed with 2018-05-20T02:51:26Z helg helg@openbsd.org 2018-05-20T02:51:26Z urn:sha1:e1487996d306181a6e7f96708e70c7a896a0016b VOP_CLOSE(9). The associated FUSE file handle is however not closed at this time and is instead closed on VOP_RELEASE(9) because that's the only time it's guaranteed to be no longer used. Directory handles are now only closed on VOP_RELEASE(9) for the same reason. ok mpi@ libfuse should not maintain state for FBT_READDIR. If a directory is 2018-05-16T13:09:17Z helg helg@openbsd.org 2018-05-16T13:09:17Z urn:sha1:390f10b55dd6db4705171d045bab12113bbe11c6 opened multiple times (either from the same process or different processes) then FUSE will not reliably return the directory entries to both file descriptors. ok mpi@ Use memset(3) instead of bzero(3) for consistency and as per POSIX 2018-05-15T11:57:32Z helg helg@openbsd.org 2018-05-15T11:57:32Z urn:sha1:bb72b40bbff2449692c2929ddea410aaf2ca013e recommendation. vn_open(9) does not pass the open(2) flags to VOP_CREATE(9) so we can't 2017-11-30T11:29:03Z helg helg@openbsd.org 2017-11-30T11:29:03Z urn:sha1:eedad28e9275b1a1371be362f2e010287ee21920 support FBT_CREATE. Fall back to FBT_MKNOD + FBT_OPEN so that a valid sequence of FUSE messages is sent to the file system when creating files. input from mpi@, otto@ Fixes the following bugs when getcwd(3) is used on a fuse file system 2017-11-17T15:45:17Z helg helg@openbsd.org 2017-11-17T15:45:17Z urn:sha1:16956dada5d0f8a8430eeb4966b6cb173751330b Endless loop if directory nested more than one level from root of file system Current directory not found if the parent directory contains more children than will fit in the buffer passed to VOP_READDIR(9) Open and close directory in fusefs_readdir if dir is not already open. Now behaves as if readdir_ino option was passed to fuse so that directories in path have a valid ino. ok mpi@ Fix fuse node lookups. Currently fusefs nodes in the kernel remember the 2016-09-07T17:53:35Z natano natano@openbsd.org 2016-09-07T17:53:35Z urn:sha1:5e69e0b69176a7f878c899ef5828a6273ab7f0bb parent inode number for ".." lookups. This only works until the kernel starts to reuse vnodes and the parent's vnode is reclaimed and the ino to path mapping is removed from the userland process by libfuse. Fix this by using reference counting in libfuse, so that parent mapping are retained as long as a child uses them. Also, don't free the root node. This commit resolves following issue: $ doas fuse-zip ~/Downloads/foo.zip /mnt $ ls /mnt openbsd-www $ grep -IR foo /usr/src > /dev/null # force vfs to reclaim vnodes $ ls /mnt ls: /mnt: No such file or directory $ ok tedu