On Wed, Jan 27, 2021 at 4:47 PM Miklos Szeredi <mszer...@redhat.com> wrote: > > On Wed, Jan 27, 2021 at 4:35 PM Greg Kurz <gr...@kaod.org> wrote: > > > > On Wed, 27 Jan 2021 16:22:49 +0100 > > Miklos Szeredi <mszer...@redhat.com> wrote: > > > > > On Wed, Jan 27, 2021 at 4:09 PM Greg Kurz <gr...@kaod.org> wrote: > > > > > > > > On Wed, 27 Jan 2021 15:09:50 +0100 > > > > Miklos Szeredi <mszer...@redhat.com> wrote: > > > > > The semantics of O_CREATE are that it can fail neither because the > > > > > file exists nor because it doesn't. This doesn't matter if the > > > > > exported tree is not modified outside of a single guest, because of > > > > > locking provided by the guest kernel. > > > > > > > > > > > > > Wrong. O_CREAT can legitimately fail with ENOENT if one element > > > > > > Let me make my statement more precise: > > > > > > O_CREAT cannot fail with ENOENT if parent directory exists throughout > > > the operation. > > > > > > > True, but I still don't see what guarantees guest userspace that the > > parent directory doesn't go away... I must have missed something. > > Please elaborate. > > Generally there's no guarantee, however there can be certain > situations where the caller can indeed rely on the existence of the > parent (e.g. /tmp).
Example from the virtiofs repo: https://gitlab.com/virtio-fs/ireg/-/blob/master/ireg.c#L315 https://gitlab.com/virtio-fs/ireg/-/blob/master/ireg.c#L382 In that case breaking O_CREAT would be harmless, since no two instances are allowed anyway, so it would just give a confusing error. But it is breakage and it probably wouldn't be hard to find much worse breakage in real life applications. Thanks, Miklos
