Bug 653054 - tcsh forgets history
Summary: tcsh forgets history
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: tcsh
Version: 17
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Roman Kollár
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-14 09:50 UTC by Arne Woerner
Modified: 2013-01-21 16:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-21 16:37:53 UTC
Type: ---


Attachments (Terms of Use)
solution that needs an additional lock file (2.34 KB, patch)
2011-10-26 11:19 UTC, Arne Woerner
no flags Details | Diff
fcntl .history file locking - shared readers, exclusive writer (12.77 KB, patch)
2012-02-16 14:03 UTC, Vojtech Vitek
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 658074 None None None Never

Internal Links: 658074

Description Arne Woerner 2010-11-14 09:50:15 UTC
Description of problem:
tcsh often empties its ~/.history file...

Version-Release number of selected component (if applicable):
> tcsh --version
tcsh --version
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,color,filec

How reproducible:
sporadic (once a day) - i dont know why...
settings:
> set | grep hist
histdup	erase
history	1000
savehist	(1000 merge)

Steps to Reproduce:
1. start csh and tcsh via gnome-terminal and crontab
  
Actual results:
after some time (funnily about at 09:00UTC the 2nd time) the ~/.history file has 0 bytes length...

Expected results:
the ~/.history file should keep the last 1000 unique commands "in mind"... :-)

Additional info:
maybe there is insufficient locking, when 2 tcsh sessions end the same time?

Comment 3 Arne Woerner 2010-11-15 17:36:35 UTC
i just had a look at the tcsh src code and found that the authors r aware of this bug (they suggest to do certain things (open, create, dump) atomically)...

a fix seems to be complicated (e g dosource() doesnt allow a "do it atomically" parameter)... :-)

i wasnt aware of that RHEL-5 bug report... maybe i should have waited just some years longer (that bug is very ooooold)... :-)) sorry for the trouble...

-arne

Comment 4 Ondrej Vasik 2010-11-15 20:34:21 UTC
As you said - to do that atomically is not so easy - and authors are aware of the issue. Vojta is new tcsh maintainer and he is now trying to make a patch and propose it to upstream (independently on this report) ... so hopefully it's not a matter of years...

Comment 5 Vojtech Vitek 2010-11-16 10:18:58 UTC
Hopefully not :)

Comment 6 Arne Woerner 2010-12-20 11:36:48 UTC
i made a workaround: (a little blunt *blush* but it works)

> grep histfile .cshrc
set histfile=`/usr/local/bin/csh-hist-workaround.sh $$`
> cat devel/chw/csh-hist-workaround.sh 
#!/bin/sh
# $Id$

cd /tmp
lockfile history.lock
touch history.fst
ls -tr history.[1-9]*.?????????? 2> /dev/null | \
while read f ; do
	pid=`echo $f | sed -e 's:^history\.::' -e 's:\..*::'`
	if pgrep tcsh | fgrep -q $pid ; then
		continue
	fi
	if [ -f history.fst ] ; then
		rm history.fst
		mv $f history
	else
		cat $f >> history
		rm $f
	fi
done
fn=`mktemp /tmp/history.$1.XXXXXXXXXX`
if [ -f history ] ; then
	cp history $fn
fi
rm -f history.fst
rm -f history.lock
echo -n $fn
> 

-arne

Comment 7 Arne Woerner 2010-12-20 13:27:15 UTC
it should be
grep -q ^$pid'$'
instead of
fgrep -q $pid

-arne

Comment 8 Arne Woerner 2010-12-26 21:43:40 UTC
here is an update of the workaround (its disk complexity is slightly better):
lockfile /tmp/history.lock
set histfile=`mktemp /tmp/history.$$.XXXXXXXXXX`
set history=2000
set histdup=erase
set savehist=(2000 merge)
test -f /tmp/history && history -L /tmp/history
foreach f ( `ls -tr /tmp/history.[1-9]*.??????????` ) >& /dev/null
   history -M $f
   history -S /tmp/history
   test -e /proc/`echo $f | sed -e 's:^/tmp/history\.::' -e 's:\..*::'` || rm -f $f
end
rm -f /tmp/history.lock

-arne

Comment 9 Arne Woerner 2011-01-26 16:41:41 UTC
i found a further optimization:
lockfile -1 /tmp/history.lock
set history=2000
set histdup=erase
set savehist=(2000 merge)
test -f /tmp/history && history -L /tmp/history
set hsn=""
foreach f ( `ls -tr /tmp/history.[1-9]*.??????????` ) >& /dev/null
   test -e /proc/`echo $f|sed -e 's:^/tmp/history\.::' -e 's:\..*::'` && continue
   history -M $f
   rm -f $f
   set hsn=1
end
set histfile=`mktemp /tmp/history.$$.XXXXXXXXXX`
test -z "$hsn" || history -S /tmp/history
rm -f /tmp/history.lock

-arne

Comment 10 Vojtech Vitek 2011-09-08 14:39:06 UTC
Arne, thank you for your help. Unfortunately, we can't use such workarounds as a final solution.

Comment 11 Arne Woerner 2011-10-26 11:19:46 UTC
Created attachment 530274 [details]
solution that needs an additional lock file

i found a new workaround...
it uses an additional lockfile, because: dosource (or so) seems to drop the lock to the history file...

Comment 12 Vojtech Vitek 2012-02-16 14:03:04 UTC
Created attachment 562503 [details]
fcntl .history file locking - shared readers, exclusive writer

Comment 13 Arne Woerner 2012-02-16 19:47:43 UTC
congratulations!
looks like a voluminous fix... :-)
but it is more elegant with a lock on the history file...
(i mean: an extra file (like in my workaround) is quite clumsy...)

-arne

Comment 14 Vojtech Vitek 2012-02-20 14:31:24 UTC
Fixed in Rawhide. Builds for stable Fedora releases coming probably with few other fixes..

Comment 15 Vojtech Vitek 2012-02-20 14:33:03 UTC
(In reply to comment #13)
> congratulations!
> looks like a voluminous fix... :-)
> but it is more elegant with a lock on the history file...
> (i mean: an extra file (like in my workaround) is quite clumsy...)

Thanks Arne! And thank you again for your help, I really appreciated that.

Comment 16 Arne Woerner 2012-04-19 17:57:32 UTC
oops
it still happens that the .history file is empty...
i think it happens when the X session is killed (e. g. with ctrl+alt+backspace)...

is it possible, that tcsh doesnt ignore signals during saving history?
or does it get a SIGKILL (which cant be ignored IIRC) (but why does it delete the history file then)?

currently i use tcsh.x86_64 (6.17-18.fc17)...

Comment 17 Vojtech Vitek 2012-05-14 21:59:27 UTC
Arne, I'm going to release new tcsh Fedora builds with the latest .history file locking changes that came from the RHEL-6 QA/testing phase. Stay tunned for the new builds - I'd be happy to hear your feedback then again.

Comment 18 Arne Woerner 2012-05-22 10:40:18 UTC
oh - ok - i thought the fix would be part of fc17 already... :-) -arne

Comment 19 Arne Woerner 2012-09-03 06:49:12 UTC
is it fixed in tcsh.x86_64 6.17-18.fc17?
i lost my history file again...

Comment 20 Arne Woerner 2013-01-20 07:36:22 UTC
did the patch reach fc18?
or what does "status: MODIFIED" mean?

i had to switch to bash, because: tcsh continued to destroy my .history file...

Comment 21 Ondrej Vasik 2013-01-20 13:58:15 UTC
Vojtech no longer maintains the package, I moved it to current maintainer.

Comment 22 Roman Kollár 2013-01-21 16:37:53 UTC
Hi, the patch made by Vojtech is not in f17, only in f18.


Note You need to log in before you can comment on or make changes to this bug.