2016-11-30 16:08 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>:

On 30 November 2016 at 15:02, Giacomo Tesio <giacomo@tesio.it> wrote:

But reading that thread I can't actually see why the OEXCL path has been taken instead of eliminating the race mapping the syscall to the 9p message.
I mean except backward compatibility.

I suppose you'll find out, but I'd expect that all but a handful of instances want the existing effect and are untroubled by any potential race.
Given that OEXCL then seems to handle the handful, it seems a reasonable approach.
The ocreate would just put the race in a different place, wouldn't it?

Well not exactly: I will use the new create syscall (without OEXCL support) when I need such level of control and use ocreate with OEXCL when I do not care about the race and want a "create or truncate" default behaviour.

But actually, I cannot see a use case where the create(2) default behaviour can be *wanted*.
I just see many use case where it can be tollerated: the create can fail anyway for other reasons so it does not add much complexity to the client...
But I'm probably missing something obvious: can you provide an example where not having the truncate fallback in the syscall actually break the program or introduce a bug. It's exactly what I'm looking for.


Giacomo