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