bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Samuel Thibault
Subject: Re: [PATCH] 1(3) hurd+glibc: Support for file record locking
Date: Sat, 2 Feb 2019 14:34:40 +0100
User-agent: NeoMutt/20170113 (1.7.2)

Hello,

Thanks for the fixes!

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...)

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.

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.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]