Potential logic bug: renaming an emptied directory fails about fscq HOT 4 CLOSED

This code unlinks an open file and then issues an fsync against the old fd; the rename orphans fd_foo.

FSCQ's specification doesn't model open file descriptors to even capture this situation, and FUSE would make it difficult to say what the actual behavior would be anyway.

If you fsync and close fd_foo before unlinking A/foo then FSCQ performs this rename correctly.

from fscq.

I see. Thanks for the comment.

An interesting observation is that rename succeeds when the same test case is executed on many other file systems, including ext4, xfs, btrfs, and f2fs.

As you would probably know, POSIX entry for unlink states that "if one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed."

So, does this mismatch of behaviors is something that result from different interpretation of POSIX specs?

from fscq.

FSCQ doesn't fully implement POSIX, especially around file handles. As you point out, the standard is clear for this example, and FSCQ deviates from the standard. Part of this is due to the complexity of modeling interactions with the operating system (eg, processes each have a directory handle to the current working directory, which needs to be modeled, not to mention their open file handles). Part of it is also that the interaction with FUSE makes it even more difficult to have full control over how a filesystem interacts with the OS.

This issue is somewhat fixable If you pass the option hard_remove as part of the -o argument to fscq. The issue is that FUSE by default implements unlink when there are open handles as a rename to .fuse_hiddenXXXXX, so that the filesystem doesn't have to deal with deleting a file's contents only when the last handle is closed. This generally makes FSCQ work closer to the POSIX standard; if you turn on hard_remove, interacting with an open but unlinked file will fail, which is also not POSIX compliant.

You might want to try running the fuse passthrough filesystem on top of ext4 and seeing what that does, especially with a variety of FUSE configurations (that is, read the options on fuse.h and see what you can toggle). I wouldn't be surprised if you find a lot of bugs there.

from fscq.

Closing. This behavior falls outside FSCQ's specification. It would be difficult to match other filesystems while using the existing FUSE interface, and I'm not sure FUSE filesystems are ever compliant in the way you're expecting.

from fscq.