Description of problem: If vim is killed (e.g. the user closes the terminal it is running in, or logs out without quitting), then the code to update the .viminfo file can (sometimes), create a .viminfz.tmp file if that exists it tries .viminfy.tmp etc. If all of .viminf[a-z].tmp exist then vim generates an error message about the .viminfo file next time it is started... Version-Release number of selected component (if applicable): vim-6.3.046-0.30E.4 The relevant code in the RHEL4 version (vim-6.3.046-0.40E.7) looks identical to me How reproducible: Most of the time... Steps to Reproduce: 1. open vim with a dummy file, enter some text 2. do a search wait about a minute... 3. kill the xterm/Terminal it is in Actual results: .viminfo.tmp is created, or .viminz.tmp etc etc.... These never get tidied up and eventually you run out of all 26 possible names (well one of my users managed it). If all of .viminf[a-z].tmp exist then on normal exit it errors with: E138: Can't write viminfo file .... Expected results: No such junk or error messages. Additional info: The code in src/ex_cmd.c to handle 'failure to open a .vim... file' seems to be what should be done if it can't pick a filename (treat it like we would if the mch_fopen() failed...) Apparently this is 'fixed' in vim-7 which is what my user has asked for, but my trivial (hack) patch seems to fix it for me. The patch adds a couple of comments in places just to get the diff output to include that context, it is really about 3 lines (close the if } earlier and add a test to call vim_free(tempname) if non-null) You may have a better solution of course.
Created attachment 130000 [details] patch to use vim_tempname() if can't pick another name.
Comment on attachment 130000 [details] patch to use vim_tempname() if can't pick another name. change mimetype
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.