You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed in fs/bridge.go, FsyncDir passes in a nil FileHandle to Fsync. But when I run sync /path/to/dir/in/vfs in a shell, I see from the FUSE logs that this issues the operations OPENDIR, FSYNCDIR, RELEASEDIR.
Since OPENDIR is called, does this mean that a file descriptor should be available, pointing to the dir, that can be passed in instead of nil? Currently, my implementation of Fsync (in the dir case) is forced to open a file, call sync on it, then close it, but since these OPENDIR / RELEASEDIR ops are issued, I wonder if we can just use the existing fd instead.
Would it make sense to keep the existing behavior to avoid breaking people, but add a new NodeFsyncDirer interface to allow people to directly operate on the fd returned by OPENDIR?
The text was updated successfully, but these errors were encountered:
bduffany
changed the title
FsyncDir passes a nil FileHandle
rawBridge passes a nil FileHandle to FsyncDir
May 25, 2023
See #460 . I have tried to make the opendir/readdir API easy to use, but the result is messy if you want to do more than opendir/readdir/closedir. OpenDir doesn't return a DirStream, so there is no place where the Go code can return your version of the directory.
However, I'm not sure if this can solve your problem. The FD that OPENDIR sends and FSYNCDIR is a pointer into a go-fuse data structure; it's not an fd that you can call fsync(2) on. You'd still have to open your file, and sync it.
I noticed in
fs/bridge.go
,FsyncDir
passes in anil
FileHandle toFsync
. But when I runsync /path/to/dir/in/vfs
in a shell, I see from the FUSE logs that this issues the operationsOPENDIR
,FSYNCDIR
,RELEASEDIR
.Since
OPENDIR
is called, does this mean that a file descriptor should be available, pointing to the dir, that can be passed in instead of nil? Currently, my implementation of Fsync (in the dir case) is forced to open a file, callsync
on it, then close it, but since theseOPENDIR
/RELEASEDIR
ops are issued, I wonder if we can just use the existing fd instead.Would it make sense to keep the existing behavior to avoid breaking people, but add a new
NodeFsyncDirer
interface to allow people to directly operate on the fd returned by OPENDIR?The text was updated successfully, but these errors were encountered: