Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[ autoload/ctrlp/mrufiles.vim ] : cache is written to hd on SIGTERM only sometimes #317

Closed
nichtleiter opened this Issue Nov 18, 2012 · 7 comments

Comments

Projects
None yet
2 participants

Hi,

first of all thanks for this great script and the effort you put into developing it.

Lately i encountered an annoying behavior with the mru-mode.

I mainly use gvim and frequently close it with a SIGTERM-broadcast via shutdown. The autocommand

au VimLeave * cal s:savetofile(s:mergelists())

is reliably called on SIGTERM but originating from the function s:savetofile, a:mrufs isn't been written to s:cafile always but sometimes.

In the case i modified the autocommand to

au VimLeave * debug cal s:savetofile(s:mergelists())

and went stepwise through all lines, a:mrufs was written successfully to hd everytime i did it that way. Without debugging and stepwise execution a:mrufs isn't written all the time.

I'm quite helpless what the cause of this strange behavior is. Maybe it's not even caused by ctrlp!?

I would be thankful if anybody who tries to reproduce it could let me know his observation and maybe tell me how to fix it!?

With best regards and thanks for your time

Johannes

Owner

kien commented Nov 19, 2012

Can you help me test to see if read/write when receiving SIGTERM is actually working for you?

From outside Vim, create a text file /home/user/test/readwrite.txt containing only one line: read. Then put this into your .vimrc and restart Vim:

let g:rwtestfile = '/home/user/test/readwrite.txt'
au VimLeavePre * cal writefile(readfile(g:rwtestfile) + ['write'], g:rwtestfile)

After you run shutdown or kill the gVim process, check if the readwrite.txt file has this:

read
write

Both this and the MRU saving work fine for me with a kill pID, which also sends SIGTERM.

Thanks for your fast reply.

Your instructions work just as expected. Everytime i send SIGTERM to gvim the line

write

is appended to /home/user/test/readwrite.txt.


To illustrate the strange behavior i observed further, i wrote a little script

#!/bin/bash
CACHE=~/.cache/ctrlp/mru/cache.txt


for i in {1..5} ; do
    rm ${CACHE}
    for j in {1..5} ; do
    gvim -c "e /tmp/mru_test_${j}" -c 'w' &> /dev/null
    sleep 0.5
    killall -s TERM gvim
    done
    cat ${CACHE}
    echo "---------------------------------------------"
done

if i run this script with no files in /tmp the output is (particular odd is, that on the first run of the inner for loop nothing is written to ${CACHE} and on the second run that mru_test_5 is not appended):

---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------

In the other case, if i run the script with the files /tmp/mru_test_{1..5} already existing in /tmp the output is (particular odd in this case is, that mru_test_5 is not appended to ${CACHE} on the first run of the inner for loop).


/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------
/tmp/mru_test_4
/tmp/mru_test_3
/tmp/mru_test_2
/tmp/mru_test_1
/tmp/mru_test_5
---------------------------------------------

Maybe these information help chasing the bug!?

Owner

kien commented Nov 19, 2012

That's interesting. Thank you! I also just tried shutdown, and apparently the readwrite.txt file above isn't changed (write isn't appended) when using shutdown. So in any case, I'll need to find a workaround for this, possibly by saving the MRU list more frequently instead of only when exiting Vim.

Interesting that this 'bug' isn't special to my setup. So, thanks a lot that you look into the matter.

Unfortunately i can't serve with any solution. Writing the cache on every BufEnter and BufLeave would be a bit exaggerated. Or maybe not!?

Best regards

@kien kien closed this in 4f7d0a3 Nov 20, 2012

Owner

kien commented Nov 20, 2012

I've added a new option: g:ctrlp_mruf_save_on_update, defaults to 1. If you find any problem with it, let me know.

I don't like it but there's really no other way. Saving on exit doesn't work when using shutdown, even when the autocmd consists of only readfile() and writefile(). Also, saving on every update is what mru.vim and others do (e.g. fuzzyfinder), ctrlp also did it by default in the beginning. It's not out of the norm.

Owner

kien commented Nov 25, 2012

I've made some new changes. Now saving only happens when a new entry is added. Changing of order won't be saved until exit or when another entry is added. This will be just enough to prevent completely losing the new entries in case Vim isn't closed normally.

Also, this was before adding the option, but in your test script, if I add another sleep instance after killall in the inner loop, then in both cases all of the 5 files are always shown.

Thanks a lot for your effort!


This will be just enough to prevent completely losing the new entries in case Vim isn't closed normally.

I encountered that lately. Probably i'will don't loose the mru files again in the future after checking out the new commits. In the other case i will let you know...

Best regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment