--=-LI7SnER0JCCjBVM+SaL+
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2007-11-15 at 12:39 +0000, Robert Watson wrote:
> > or Solaris NFS clients. Basically, Timo (cc'ed) came up with a small te=

st=20
> > case that seems to indicate sometimes a link() call can succeed while t=

he=20
> > link count of the file will not increase. If this is ran on two FreeBS=

D=20
> > clients from the same NFS directory, you will occasionally see "link()=20
> > succeeded, but link count=3D1". I've tried both a Netapp and a FreeBSD=

NFS=20
...
> My guess, and this is just a hand-wave, is that the attribute cache in th=

e NFS=20
> client isn't being forced to refresh, and hence you're getting the old st=

at=20
> data back (and perhaps there's no GETATTR on the wire, which might hint a=

t=20
> this). If you'd like, you can post a link to the pcap capture file and o=

ne of=20
> us can take a look, but I've found NFS RPCs to be surprisingly readable i=

n=20
> Wireshark so you might find it sheds quite a bit of light.


Actually the point was that link() returns success even though in
reality it fails. The fstat() was just a workaround to catch this case
and treat link count 1 as if link() had failed with EEXIST. After that I
had no more problems with locking.

I noticed this first because my dotlocking was failing to lock files
properly. I also added fchown() to flush attribute cache after link()
and before fstat(), it gives the same link count=3D1 reply.


--=-LI7SnER0JCCjBVM+SaL+
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHPEWgyUhSUUBViskRAgdUAJ9oxcaapCx9OHuzztVA0D CjGA4VkwCgjZ3j
cILNJPWfmbnGnqjX9NPnaxM=
=6qV6
-----END PGP SIGNATURE-----

--=-LI7SnER0JCCjBVM+SaL+--