Date: Wed, 26 Aug 2009 17:06:40 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: freebsd-fs@freebsd.org Subject: Re: semantics of fcntl() with l_len being 0 Message-ID: <20090826140640.GA9623@deviant.kiev.zoral.com.ua> In-Reply-To: <4A953F30.8030202@aldan.algebra.com> References: <4A94B829.3090202@aldan.algebra.com> <20090826090947.GS9623@deviant.kiev.zoral.com.ua> <4A953F30.8030202@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--cgV9kgQ4vUfIQsP4
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 26, 2009 at 09:57:04AM -0400, Mikhail T. wrote:
> Kostik Belousov =CE=C1=D0=C9=D3=C1=D7(=CC=C1):
> > On Wed, Aug 26, 2009 at 12:20:57AM -0400, Mikhail T. wrote:
> > =20
> >> Hello!
> >>
> >> I'm curious, whether a file, that's locked (via fcntl) with l_start and
> >> l_len being 0 is supposed to be appendable...
> >>
> >> I would think so, but I notice, that when spamprobe (see mail/spamprob=
e)
> >> chews on my spam mailbox, I can not append a new piece of spam to the
> >> file -- my imap-server is waiting for spamprobe to finish.
> >>
> >> The fcntl(2) says: ``len =3D 0 means until end of file''. Is that ``un=
til
> >> the end of file AT THE TIME OF LOCKING'' or simply ``no other lock unt=
il
> >> we are done''? Thanks. Yours,
> >> =20
> >
> > SUSv3 is definitive on the subject:
> > A lock shall be set to extend to the largest possible value of the file
> > offset for that file by setting l_len to 0. If such a lock also has
> > l_start set to 0 and l_whence is set to SEEK_SET, the whole file shall
> > be locked.
> > =20
> I would not say, this is definitive -- if one attempts to grow a locked
> file, "the whole file" (as existed at the lock-time) will remain
> non-violated... The code is more explicit, of course:
> > From sys/kern/kern_lockf.c, line 464:
> > } else if (fl->l_len =3D=3D 0) {
> > end =3D OFF_MAX;
> > =20
> So, how can one properly lock only the area, that exists at the time of
> locking? Perform a stat() first? Thanks!
You might lock the maximal range, to prevent the modifications from other
accessors that honour the protocol, do stat call, and then unlock
the range from EOF to 0 (AKA max offset).
--cgV9kgQ4vUfIQsP4
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkqVQW8ACgkQC3+MBN1Mb4jh7gCg3xq2JSaFOFkMDpgzn4lbb6AL
QBUAoMhiprq3bzbjyG+3TLbHCPe0SRKi
=fPX3
-----END PGP SIGNATURE-----
--cgV9kgQ4vUfIQsP4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090826140640.GA9623>