Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
ksh is login shell.
On desktop, start multiple xterm -ls -sb -vb -geom 80x43
HISTFILE and HISTSIZE are set and HISTFILE contains at least HISTSIZE
commands.
(in my case HISTSIZE==20000 and more than 12 xterms).
Log out saving desktop layout.
When logging back into desktop, xterms are restarted in background.
Each ksh checks whether HISTFILE needs to be truncated to HISTSIZE commands.
There is a race condition and no lock between when ksh instances check
size of HISTFILE and when they truncate it.
Maybe flock would fix this?

Work around: exit all but one xterm before logging out.

So far as I can remember, this bug has existed since at least 1988 but did
not often bother me until desktops started xterms in the background.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***

Does your file system support flock() or the fcntl() locking apis? How
does bash work around the problem?

Ced

Does your file system support flock() or the fcntl() locking apis? How
does bash work around the problem?

Ced

Thanks for your response.

I have thought about this a little more. flock() is not likely to be the
solution. It would likely lead to deadlock sometimes. That is probably why
it has not been fixed previously.

I have not used bash much since ksh became open source. So far as I can
remember, bash had the same problem several years ago.

My file system is ext3. I had not thought about file systems without
flock or fcntl.

Maybe creating a temporary lock file in the same directory as the history
file and containing pid and time stamp. If time stamp is more than 5 seconds
old then break lock. ???? I am not at all certain this makes sense.

Thanks again.

John