What should a file system do if asked to create a file that already exists?

[jacobsa]

What are the expections of osxfuse when the userspace daemon is sent a create request, but the file already exists? Should it return EEXIST, just open the file, or what?

Some notes on what I've determined experimentally:

• If I call open(2) with several workers in parallel using O_CREAT, on Linux I only ever receive a single create request, but with osxfuse I receive many. So I conclude that Linux is holding a lock around the "look up, find doesn't exist, send create request" process, but osxfuse isn't.
• Of course this question still applies on Linux if a file may be created remotely, so that it springs into existence after the kernel does a lookup but before it calls create.
• Unless I've missed something, osxfuse doesn't seem to pass on the O_EXCL flag to the userspace daemon, so the daemon probably can't be responsible for deciding whether it is safe to open the file if it already exists.
• Returning EEXIST appears to do the right thing whether O_EXCL is set or not, but just opening fails to work right if O_EXCL is set.

[jacobsa]

Also worth noting: I see the same Linux/OS X behavior difference for creating a symlink and creating a directory: in both cases, Linux excludes concurrent creation, but OS X doesn't. (This is fine, as long as I know what I'm expected to do when it happens.)

[yobert]

I'm pretty sure returning EEXIST is the right thing to do. O_EXCL I think would try to get an exclusive lock on the file handle after creation but before returning. So whether or not you can see O_EXCL, you probably want to fail with EEXIST.

[bfleischer]

The macOS kernel expects all create calls to return EEXIST in case the file already exists, regardless of whether O_EXCL was specified for the original create call or not. To ensure this, starting with version 3.4.1, the FUSE kernel extension will set the O_EXCL flag for every FUSE_CREATE request sent to user space.

Apple states in hfs_vnop_create:

We leave handling of certain race conditions here to the caller which will have a better understanding of the semantics it requires. For example, if it turns out that the file exists, it would be wrong of us to return a reference to the existing file because the caller might not want that and it would be misleading to suggest the file had been created when it hadn’t been. Note that our NFS server code does not set the VA_EXCLUSIVE flag so you cannot assume that callers don't want EEXIST errors if it's not set. The common case, where users are calling open with the O_CREAT mode, is handled in VFS; when we return EEXIST, it will loop and do the look-up again.

I've added a new mount-time option to add some flexibility for network file systems:

If the mount-time option excl_create is specified, the O_EXCL flag will only be set for "truly" exclusive creates, i.e. create calls for which the initiator explicitly set the O_EXCL flag. This allows network file systems to determine whether or not to acquire a potentially costly lock to prevent remote create races. Nonetheless, the file system still needs to make sure that there are no local create races.

[jacobsa]

@bfleischer: thank you very much for the explanation! Could you link to the source of the quote from Apple? I'm not familiar with VFS documentation for darwin, and would love to have a reference to consult.

[bfleischer]

The quote is from the following XNU source file:

http://opensource.apple.com//source/xnu/xnu-3248.40.184/bsd/hfs/hfs_vnops.c

[jacobsa]

Ah I see. Thanks!

[tv42]

I think excl_create should really be the default. It's how the linux side behaves anyway, and it only makes sense that an operation called create insists on creating something.

[bfleischer]

I disagree, the OS X kernel expects create to fail if the file already exists. When auto-setting O_EXCL for every create you can use the same callback code on Linux and OS X and it should always be semantically correct, with regard to the kernel, whether the file system runs on Linux or OS X. Am I missing something?