Re: crontab and editors (was Re: Editor Priorities)
>>"Steve" == Steve Greenland <steveg@moregruel.net> writes:
Steve> Crontab works like this roughly:
Steve> 0. open /tmp/funnyname
Steve> 1. copy existing /var/spool/cron/crontabs/whatever to /tmp/funnyname
Steve> 2. start ($VISUAL|$EDITOR|/usr/bin/editor) on /tmp/funnyname,
Steve> wait for child to exit.
Steve> 3. if stat.modtime(/tmp/funnyname) hasn't changed, then goto
Steve> 7.
Hmm. this could be a different inode from the one we had opened.
Steve> 4. rewind(/tmp/funnyname)
reopen, instead of rewind.
Steve> 5. check that /tmp/funnyname parses
Steve> 6. copy /tmp/funnyname /var/spool/cron/crontabs/whatever
Steve> 7. rm /tmp/funnyname
Steve> (All without closing /tmp/funnyname between 1 and 7).
That is the bug. You are making assumptions about the
environment that are not warranted, based on how some popular editors
work.
Steve> How is this broken - Other than in the presence of editors that do
Steve> backups incorrectly. :-)
The assumption that the inode has not changed is the breakage.
I should have read the whole thread before posting (I thought there
was a tmp race y'all were talking about), but this is still a problem
with crontab. (incidentally, I just use crontab ~/etc/crontab, and thus I
never noticed this bug).
manoj
--
If someone says he will do something "without fail", he won't.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: