Re: crontab and editors (was Re: Editor Priorities)
Steve Greenland <steveg@moregruel.net> writes:
> On 08-May-02, 16:12 (CDT), Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
>> Steve Greenland <steveg@moregruel.net> writes:
>> > Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
>> >> Steve Greenland <steveg@moregruel.net> writes:
>>
>> >>> * Edits files in place, rather than moving/copying +20
>> >>>
>> >>> See crontab(1) for why.
>> >>
>> >> Why can't crontab be fixed?
>> >
>> > Crontab isn't broken[1].
>>
>> Well, it certainly sounds like it's broken to me...
>
> Crontab works like this roughly:
>
> 0. open /tmp/funnyname
> 1. copy existing /var/spool/cron/crontabs/whatever to /tmp/funnyname
> 2. start ($VISUAL|$EDITOR|/usr/bin/editor) on /tmp/funnyname, wait for child
> to exit.
> 3. if stat.modtime(/tmp/funnyname) hasn't changed, then goto 7.
> 4. rewind(/tmp/funnyname)
> 5. check that /tmp/funnyname parses
> 6. copy /tmp/funnyname /var/spool/cron/crontabs/whatever
> 7. rm /tmp/funnyname
>
> (All without closing /tmp/funnyname between 1 and 7).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's a blatantly obvious bug.
> How is this broken - Other than in the presence of editors that do
> backups incorrectly. :-)
Rename-into-place is a desirable feature in editors (and in many other
programs) because it means that if the process has to stop writing
part way through saving, the original is still available via the
expected name. It might have to stop due to an error such as ENOSPC,
receiving a fatal signal, or power failure.
If you just truncate and rewrite the file to save it, then any of
these conditions can lose you data, which is at least a grave bug on
Debian systems.
If you save a separate backup copy, and then truncate and rewrite,
then you don't lose any data when things go wrong, but the data is in
the wrong place and the file you were editing is mangled in some way.
That's at least inconvenient, and is disastrous for some files.
Obviously in the case of crontab since you're only editing a temporary
copy it doesn't matter if it gets trashed in this way. But crontab is
not the only application for these editors; they are used for data
that we care about, too.
crontab should be fixed, both to avoid /tmp and to use a sensible
algorithm for detecting when the file changes. Or not bothering to
detect when the file changes - why does it need to know anyway?
--
http://www.greenend.org.uk/rjk/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: