This is a minor annoyance, perhaps someone has a better idea to fix it other than "use nano as your EDITOR"
Latest version available: 3.0.1-r2
Latest version available: 6.2-r3
REPRODUCING THE PROBLEM:
1. Put "vim" in your rc.conf as EDITOR.
2. As root try
3. Make your cron entry, save and quit. (vim: i, wq)
4. Note that your crontab was not saved.
See the included URL for what seems to be a good technical description of this problem.
This should be considered a vcron problem, not a vim problem. There's no
reason to assume (on vcron's part) that the file will be overwritten instead
my EDITOR variable is set to vim, and I can save cronfiles perfectly fine within vim.
I'm using vcron 3.0.1-r1
I've just tested as well, using EDITOR=vim and vcron-3.0.1-r3. This seems
to work fine.
I may have solved the mystery at least.
if /tmp is a symbolic link, vim isn't gonna work for your cron editing.
Maybe I'm spouting gibberish, but it seems to me the file vim edits and the file crontab has an open filehandle to are not the same, they'll have different inodes but the same name. How is that possible? Who knows. I'm just repeating what I read in the included URL. The file is replaced, but crontab still has an open handle to the previous file.
Using crontab and vim on a /tmp as regular directory and as a bind mount worked. I can reproduce when /tmp was a symlink it didnt work, which doesn't make any sense to me.
This is the relevant comment in the crontab code:
/* we still have the file open. editors will generally rewrite the
* original file rather than renaming/unlinking it and starting a
* new one; even backup files are supposed to be made by copying
* rather than by renaming. if some editor does not support this,
* then don't use it. the security problems are more severe if we
* close and reopen the file around the edit.
I agree with the decision, because of the security issue, so I won't modify it to close and reopen the temp file.
Well I don't see any obvious reason as to why this is happening, and vixie-cron hasn't been maintained upstream in a while. Having /tmp as a symlink is odd; I suggest using a bind mount.