Re: [PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

On Sat, 2019-02-02 at 14:34 +0100, Samuel Thibault wrote:
> Hello,
> 
> Thanks for the fixes!

YW!

> Svante Signell, le sam. 02 févr. 2019 11:52:56 +0100, a ecrit:
> > On Sun, 2018-12-30 at 21:21 +0100, Samuel Thibault wrote:
> > > Svante Signell, le sam. 22 déc. 2018 13:07:37 +0100, a ecrit:
> > > >  diskfs_S_file_lock (struct protid *cred, int flags)
> > > >  {
> > > ...
> > > > +  /* XXX: Fix for flock(2) calling fcntl(2) */
> > > > +  if ((openstat & O_RDONLY) && !(openstat & O_WRONLY)) openstat |=
> > > > O_WRONLY;
> > > > +  if (!(openstat & O_RDONLY) && (openstat & O_WRONLY)) openstat |=
> > > > O_RDONLY;
> > > 
> > > I don't understand this: in which application case is this needed?
> > 
> > I added this when running tests for flock(2) and comparing the behaviour
> > with Linux, see the test file libfshelp-tests/test-flock.c.
> 
> Do you mean: in the case of a file opened without WR open mode, taking
> an exclusive lock would fail otherwise?
> (really, that's the bit of information I was looking for, having to
> guess it is errorprone...)

Yes, I think that was the problem. I have to re-run the tests to be sure, it was
some time ago since I made those changes.

> Continuing on guesswork, I guess you noticed that Linux allows to take
> an exclusive lock with flock even without WR open mode?
> 
> If that's so, then indeed the fcntl lock doesn't allow it (as mentioned
> in POSIX:
> 
>   A request for an exclusive lock shall fail if the file descriptor was
>   not opened with write access.
> 
> But we only want to fix that case, and not just blindly set open modes
> without an explained rationale.

OK!

> So can you confirm my guesswork above? If, so, then only keep the first
> line (the second line doesn't make sense in my guesswork), and mention
> that while fcntl requires WR access for exclusive lock, flock doesn't.

Ok, I'll run the tests again, make those changes and reupload.