From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: If the temporary crontab file provided by crontab -e for the editor is edited in under 1 second, the edit is not noticed, and not loaded. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.create a script that accepts a filename as argument, and adds valid crontab lines (eg: * * * * * /bin/echo "something") to that file. 2.set that script to be the editor for crontab -e by doing: export EDITOR=/path/to/editorscript 3.run crontab -e Actual Results: the temp file gets modified in under 1 second, so the modtime of the tempfile that crontab -e created is not updated. Crontab checks the modtime and finds no change, so it doesn't load the file. (modtime being the value of st_mtime in the stat struct) Expected Results: This change should be detected, regardless of how fast it the editor edits the script. Perhaps if it checked st_size and st_mtime instead of just st_mtime. Additional info: Since st_mtime is in seconds, any edit that takes less than one second is not visible to crontab -e. A simple work around for scripts that act as editors for crontab is to make them sleep for a couple seconds before writing to the file, so that st_mtime can be updated.
An even simpler workaround is just to use stdin, ie.: $ myscript | crontab would replace the current user's crontab with the output of 'myscript'. The 'crontab -e' mode exists to enable crontab editing by human users. No human users could ever complete an edit in less than a second , (if you can prove otherwise, please feel free to do so!:) and we already provide a way for non-human users to replace crontabs - see above. Hence, this bug is being closed as "not a bug" . However, I will look at using the 64-bit time in stat->st_mtim.tv_usec in future releases (st_mtime is #define'd to st_mtim.seconds on 2.4+ kernels).