Bug 37994 - crontab -e doesn't work with vim
Summary: crontab -e doesn't work with vim
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vixie-cron   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: David Lawrence
: 41291 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-27 05:50 UTC by redhat
Modified: 2007-04-18 16:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-07 22:36:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description redhat 2001-04-27 05:50:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [de] (X11; U; Linux 2.2.16-3 i686; Nav)

'crontab -e' doesn't recognizes changes when used with VISUAL=vim.

Reproducible: Always
Steps to Reproduce:
1.VISUAL=vim crontab -e
2.edit crontab and quit vim
3.crontab says nothing has changed

Actual Results:  crond isn't notified so the changes made to any crontab
recognised until next reboot (or restart of crond)

Comment 1 Daniel Roesen 2001-04-27 08:43:26 UTC
I cannot reproduce this.

[root@alexis /root]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab
[root@alexis /root]# VISUAL=vim crontab -e
crontab: installing new crontab

Comment 2 Daniel Roesen 2001-04-27 08:44:46 UTC
Changing component to vixie-cron, as "crontabs" is wrong.

Comment 3 redhat 2001-04-27 16:34:29 UTC
I still get this error on every call of 'crontab -e' (well the VISUAL is either set to 'vi' or left blank).

[root@fantasy /root]# uname -a
Linux fantasy.erik-kunze.de 2.4.3 #8 Mit Apr 25 22:32:49 CEST 2001 i686 unknown
[root@fantasy ar3]# echo $VISUAL
[root@fantasy ar3]# echo $LANG
[root@fantasy ar3]# crontab -e   <- made changes
crontab: no changes made to crontab

Comment 4 redhat 2001-05-03 19:27:34 UTC
Get a strace log from http://www.philosys.de/~kunze/crontab.strace

Comment 5 John Villalovos 2001-08-30 21:27:28 UTC
Is /tmp a softlink to somewhere?  I am having the same problem and my /tmp is a 

Comment 6 redhat 2001-08-31 05:04:25 UTC
Haven't you get the supplied strace logfile? And yes, /tmp is symlink to
/var/tmp (why should one keep two temporary directories on one filesystem).
However, would you finally fix this bug!

Comment 7 adastra 2001-09-04 21:04:09 UTC
Ditto for me, on a machine with /tmp as a softlink to /var/tmp on a different
partition.  emacs & pico have no problem, vim fails exactly as described above.  
	If I :w and ^Z, I can see the intended crontab intact in /tmp, but then after
quitting, all changes are lost.

Comment 8 Mike Fleetwood 2001-11-27 22:13:42 UTC
I encounter the same problem.  See my email in the LKML:

To summarise when Vim 6.0z BETA (from RedHat 7.1) saves a file it results in a new file with a new inode being created, but keeping the old name.  As crontab has an open file handle on the old inode it sees no change.  I solved this by down grading to Vim 5.7 (from RedHat 7.0) which saves the text in the origional inode.

There are three possible solutions:
1) Change crontab to close the file handle and reopen the it after the editor completes, but there is a warning in crontab.c:edit_cmd() saying that this is a security risk;
2) Change Vim so that it writes back to the origional inode as it use to do.  You should check with the Vim developers (http://www.vim.org/) as to why this changed just in case; or
3) Choose a different editor.

Comment 9 Need Real Name 2001-11-27 22:39:33 UTC
A workaround for Emacs users: when you're about to save the crontab file, do
        M-x make-local-variable RET backup-by-copying RET
        M-x set-variable RET backup-by-copying RET t RET
Now when you save the file, Emacs will keep the same inode, so cron will notice 
your changes.

Comment 10 Eido Inoue 2002-02-12 19:26:24 UTC
*** Bug 41291 has been marked as a duplicate of this bug. ***

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