>> 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.
>
>Yes, this does solve this particular sub-class of the "has this file
>been written to" problem.  However this only solves the problem if the
>parent process has made a copy of the file to be manipulated.

well...uh...yeah.  but in the case where the parent process *hasn't*
made a copy, the newly-perhaps-saved file doesn't need to be "checked
in".  unless you're thinking of some other application like this?

-- 
|-----< "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."