Re: Issues with fcntl() history file locking

[Philippe Troin <phil@xxxxxxxx>]

On Wed, 2019-02-27 at 22:36 -0800, Philippe Troin wrote:
> On Wed, 2019-02-27 at 13:27 -0800, Bart Schaefer wrote:
> > On Wed, Feb 27, 2019 at 10:31 AM Philippe Troin <phil@xxxxxxxx>
> > wrote:
> > > 
> > > The right and hard way is to have the various calls to open() the
> > > history file to actually use the flock_fd lock file descriptor
> > > (and not close it when done with it, leaving that to
> > > unlockhistfile()).
> > > 
> > > The easy messy way is to keep track of all the open descriptors
> > > to the history file in a global variable, and delaying the actual
> > > close until unlockhistfile() is called.
> > 
> > If this actually turns out to be necessary, the second way is more
> > similar to how we handle descriptors in other parts of the shell.
> 
> I'll do further experiments.
> 
> This is my current hunch:  everything is swell as long as lines are
> appended to the history file.  But, when one host decides it's time
> to
> trim the history file is when stuff hits the fan.  If someone had an
> idea on how to force zsh to trim history reliably, I'm all ears.

So, I've implemented what I described (delaying closing the file
descriptors and handles until unlock time).
The rough patches will follow shortly.

But, it doesn't help the problem at all:  I've been running 5.7.1 +
that patch on a small network, and I ran into the same issue again :-/
Back to the drawing board...
It's something else that's happening.

I'll let you decide if the patches are worth inclusion or not.
Since it doesn't fix any actual issues, probably not, even though this
is supposed to be more correct to avoid history corruption on network
filesystems when hist_fcntl_lock is active.

Phil.