[ On Saturday, May 29, 1999 at 13:57:20 (-0400), TheMan wrote: ]
> Subject: bin/7662: crontab(1) does not always save changed crontab file
>
> this looks right to me.  just check the size of the new file vs. the
> size of the old file.  of course...you will still lose if the changes
> you make (a) take less than a second to perform, and (b) result in a
> same-sized file.

It seems to me like a waste of time and bother to even try to check if
the file was modified -- it should not matter if the daemon gets "poked"
for no reason (there are many better ways to cause problems with cron
than this!).

On the other hand, I wonder what would break and what the performance
impact would be if the *kernel* were to force a process to pause on
close (not on write) until the second ticks over and then to update the
timestamps (i.e. iff it knows the file has been written to)....  (0.25 ;-)
I can think of lots of things, like this crontab problem and a zillion
make related problems, that it would *fix*.  [You wouldn't want to not
pause the process or you'd open up a loophole that would allow a rogue
process to push a file timestamp into the future.]

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>