LLNL
`unifyfs_create` is not exclusive
System information
| Type | Version/Name |
|---|---|
| Operating System | Ubuntu |
| OS Version | 21.04 |
| Architecture | x86_64 |
| UnifyFS Version | -dev |
Describe the problem you're observing
unifyfs_create is supposed to fail if a unifyfs file of the same name already exists. It does not
Describe how to reproduce the problem
Here's a test case: https://gist.github.com/roblatham00/3fbac27c231f9773a64e35d0933c9b31
it deletes the file, creates the file, then creates the file again. Both creates succeed, though I thought the second create should fail.
Include any warning or errors or releveant debugging data
The client log indicates the RPC failed, but unifyfs_create still returns 0:
...
2021-09-16T13:43:33 tid=27233 @ invoke_client_metaset_rpc() [margo_client.c:426] invoking the metaset rpc function in client - gfid:274250918 file:/unify-demo/try1
2021-09-16T13:43:33 tid=27233 @ invoke_client_metaset_rpc() [margo_client.c:440] Got response ret=17
2021-09-16T13:43:33 tid=27233 @ invoke_client_metaget_rpc() [margo_client.c:474] invoking the metaget rpc function in client
2021-09-16T13:43:33 tid=27233 @ invoke_client_metaget_rpc() [margo_client.c:487] Got response ret=0
I'd sure like that 'ret=17' to make its way out to the caller!
Hi @roblatham00. Finally getting around to looking at this and wondering if this double create pattern is from a real use case. It's fairly easy for us to ensure that a duplicate unifyfs_create() from the same client sees EEXIST, but I don't know how useful that limited behavior would be to you.
I am a little hazy about what prompted me to construct this test case, but it was ROMIO related: flags to open can include both CREATE (create the file) and EXCL (exclusive create: if the file already exists that is an error). These flags are not unique to ROMIO. posix also has O_CREAT and O_EXCL.
Right now I'm perfectly happy with single-client exclusive create. If there's a "file creates on one process look like writes" semantic for UNIFY, I'm happy to go along with that in ROMIO.
It appears this was resolved for the 1.0 release. Any objections to close this one?
