Prevent rename() spuriously returning ENOENT.

[EdSchouten]

I'm implementing a file system that does its own bookkeeping of files stored in a directory. I need to do this, due to the file sytem also being accessible without going through FUSE. At certain phases, it's even the case the file system is only in-memory and not even exposed through FUSE.

To keep things simple, I've made it so that upon renames and unlinks, I only call into RmChild(). I rely ook Lookup() to expose files once again afterwards. This approach currently causes me to observe some spurious ENOENTs due to the EBUSY check for mount point renaming. Move both checks into one, eliminating the ENOENT return.

[hanwen]

can you rephrase this without referencing your specific FS, but what general pattern you want to support?

explain why returning ENOENT is not necessary (kernel issues LOOKUP to verify that the source exists)

[rfjakob]

Not sure what the problem for the OP is, but the check at https://github.com/hanwen/go-fuse/blob/8020c1880dbdc4bcc1834e9786407edbc3872bdb/fuse/nodefs/fsops.go#L322 is racy in any case, isn't it? The file may have disappeared by the time we reach oldParent.fsInode.Rename()

[hanwen]

I think the VFS has locking to prevent the race. Of course, if change the tree behind the kernel's back, things might still go wrong, and you have to have locking on the FS implementation

[hanwen]

is this still an issue with the fs API ?

[EdSchouten]

Hey! Unfortunately I wouldn’t know. In the meantime I have switched to just using RawFileSystem which works great for me.

Happy to close this if desired.