>> Refining the granularity of FS timestamps would sure be a better idea (when
>> we move to 2038 safe timestamps...)
>
>Trying to refine the granularity of FS timestamps is a never-ending and
>thankless job (at least until Moore's Law hits "The Wall"), i.e. it's
>definitely *not* the most elegant solution.  In fact I've always
>considered it to be the least elegant solution, especially in a portable
>operating system.

granted.

>My suggestion is guaranteed to always avoid the problem, regardless of
>the granularity of timestamps.

someone else (my apologies, but i can't recall who off the top of my
head) posted a rather *elegant* solution to the problem that would
acheive the desired effect, and at the same time not require
microsecond file update times or anything quite so implementation
dependent.

the proposition: simply to adjust the mtime of the temp file back to
the mtime of the original crontab file being edited.  any saved data
would automatically move the mtime to "now", providing proff that the
file was at least saved, if not changed.  then you'd only lose if you
did two complete edits within one second.  things being what they are,
i only discovered this bug because i was trying to do one edit within
a second.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."