Geoff Kuenning wrote:
> Linda:
>
> I actually don't use histappend; I like the fact that history eventually
> disappears.
----
I'm not one to try to sell something so trivial, but do you really
never have a project that lasts more than 1 login session where repeat
commands would be useful?
If you embed the date, you can run a script to delete them after 1,
3, 6 months... or whatever... I'd be even more lost w/o my history...though
I admit to packrat-ish tendencies... so have to take this opinion as colored
by that...;-) (truth in advertising is me)...
As for the problem...the fact that you using 4.2, would seem
to make the algorith
open(<zero as new file>)
write(whatever we have as history)
close(set eof to where we are).
What file system are you are? is it local or networked?
one way for it to be zero is if the last bash exiting had no history,
cuz the zero/truncate of each open can zero the file from any previous
bash being left.
I can also see the possibility of some kernel or file system routine
waiting after you issue the close call so that it doesn't have to zero
the area where data is arriving. I.e. it might only zero the file beyond
the valid text AFTER some delay (5 seconds?) OR might wait until the file
is closed, so if you completely overwrite the old file with text, the
kernel won't have to zero anything out.
Imagining a race condition that could exist (but pure speculation
proc1 OT .... write ......... close
proc2 OT...write...close
proc3 OT.......close (no content), but it's close triggers the
zeroing of
the file which zeros out what proc1 & 2 have written. (unlikely bug possible)
or another possibility
proc1 OT .......write close
proc2 OT..write..close
proc3 OT...writeclose
in the case of write...close to non-pre-zeroed record, the operation
becomes a read-modify-write. Thing is, if proc 3 goes out for the partial
buffer
(~4k is likely), it may have been completely zeroed from proc2 closing where
proc3
wants to write.
I'm pretty tired, so if the above sounds confused or confusing, ignore it...;-)
(multi-threaded ops on real multiple execution units do the darnest things).
