-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What should a file system do if asked to create a file that already exists? #209
Comments
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.) |
Added tests that confirm behavior of "real" file systems, then made memfs make those tests pass, too. Doing this by returning EEXIST appears to work on both OS X and Linux, but I can't find documentation anywhere that says this is what is expected. More: osxfuse/osxfuse#209 http://stackoverflow.com/q/30364838/1505451 http://sourceforge.net/p/fuse/mailman/message/34130996/
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. |
The macOS kernel expects all create calls to return Apple states in
I've added a new mount-time option to add some flexibility for network file systems: If the mount-time option |
The macOS kernel expects all create calls to return EEXIST in case the file already exists, regardless of whether O_EXCL was specified or not. 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. Resolves osxfuse/osxfuse#209
@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. |
The quote is from the following XNU source file: http://opensource.apple.com//source/xnu/xnu-3248.40.184/bsd/hfs/hfs_vnops.c |
Ah I see. Thanks! |
I think |
I disagree, the OS X kernel expects create to fail if the file already exists. When auto-setting |
Hrmm. You seem to be right, and my understanding of the linux behavior is wrong. Sorry for the noise. This is really unfortunate :( |
What are the expections of osxfuse when the userspace daemon is sent a
create
request, but the file already exists? Should it returnEEXIST
, just open the file, or what?Some notes on what I've determined experimentally:
O_CREAT
, on Linux I only ever receive a singlecreate
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.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.EEXIST
appears to do the right thing whetherO_EXCL
is set or not, but just opening fails to work right ifO_EXCL
is set.The text was updated successfully, but these errors were encountered: