search for: 5ww

...SIZE/OFF NODE NAME cat 13543 eric 5w REG 8,9 0 930437 tmp.db/flintlock cat 13552 eric 9w REG 8,9 0 930437 tmp.db/flintlock Blaming the execl is due to stepping though my copy of the lock code in gdb, and seeing, in lsof, 5w on the open, still 5w on the fork, 5ww on the fcntl, and 5w again on the execl. > I wonder if the problem is unrelated to locking, but instead it's that > the Tcl database doesn't get explicitly destroyed in your script, so > that the C++ object doesn't either, and the changes don't get committed. > > I...

I discovered, while trying to set up Tcl bindings for Notmuch (https://notmuchmail.org/), which uses Xapian, that flintlock was not being locked (I had lost updates). I then found that opening a Xapian database for writing directly via the Xapian Tcl bindings also silently fails to lock flintlock. I have taken a copy of flint_lock.cc to play with, and I find that it locks the file when called

...would sound sensible, but I have stepped through the code (my copy, obviously) with gdb, checking on the file with lsof in another session. The sequence is definitely: open fork lock execl with the file showing up in lsof as 5w after the open, staying through the fork, changing to 5ww with the lock, and back to 5w with the execl. Which isn't supposed to happen according to any docs I can find. Thanx, Eric -- ms fnd in a lbry

...cat 13543 eric 5w REG 8,9 0 930437 tmp.db/flintlock > cat 13552 eric 9w REG 8,9 0 930437 tmp.db/flintlock > > Blaming the execl is due to stepping though my copy of the lock code in > gdb, and seeing, in lsof, 5w on the open, still 5w on the fork, 5ww on > the fcntl, and 5w again on the execl. Odd, as you said elsewhere, execl() shouldn't drop the lock. It would be good to get to the bottom of this, as unreliable locking is a bad thing to have. What FS are you running this on? Is use of Tcl actually a factor here, or can you reproduce...

...ric 5w REG 8,9 0 930437 tmp.db/flintlock >> cat 13552 eric 9w REG 8,9 0 930437 tmp.db/flintlock >> >> Blaming the execl is due to stepping though my copy of the lock code in >> gdb, and seeing, in lsof, 5w on the open, still 5w on the fork, 5ww on >> the fcntl, and 5w again on the execl. > > Odd, as you said elsewhere, execl() shouldn't drop the lock. It would > be good to get to the bottom of this, as unreliable locking is a bad > thing to have. > > What FS are you running this on? ext4 > Is use of Tcl...

...C9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYWUTUgUYRjH /7ONBLEG0ZcIxdDBJFQmC1IC0/UrU7Zl1UwJYp19d50cZ6eZ3S1FIoTomHWMLlZEh4hO4aFDpzpE BJl1iaCjRRAFXiK2/zuTu2NUvjAzv3me//t8vcMAVY9SjmNFNGDKzrvJ3ph2enRM2/waVahGFFwp w3M6EokBn6mVz/Vr9S0UaVlqlLHW+zZ8q3aZEFA0KndkAz4seTzg45Iv5J08NWckGxOpNNkhN7hD yU7yLfLWbIjHQ5wWngFUtVOTMxyXcSI7yC1FIytjPiDrdtq0ye+lPe0ZU9Sw38g3OQvauPL9QNse YNOLim3MAx7cA3bXVWz1NcDOEWDxUMX2PenPR9n1ysscavbDKdEYa/pQKn2vAzbfAH5eL5V+3C6V ft5hDtbx1DIKbtHXsjDlJRDUG+xm/OQa/YuDnnxVC7DAOY5sAfqvADc/AvsfAtsfA4lqYKgVkcts N7jy4iLnAnTmnGnXzE7ktWZdP6J18GiF1mcbTQ1ayrI03+VprvCEWxTpJkxZBc7ZX9t4jwp7eJBP 9he5JLzu...