rawBridge passes a nil FileHandle to FsyncDir

[bduffany]

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?

[hanwen]

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.