2016-11-30 16:08 GMT+01:00 Charles Forsyth <[email protected]>:
> > On 30 November 2016 at 15:02, Giacomo Tesio <[email protected]> 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
