[ On Tuesday, June 1, 1999 at 03:45:38 (+0100), Ronald Khoo wrote: ]
> Subject: Re: bin/7662: crontab(1) does not always save changed crontab file
>
> I certainly don't see that this is particularly inelegant, it's certainly
> less inelegant than using st_mtime which doesn't even give the right
> answer if timestamps aren't granular enough.

I think the explicit flag is somewhat less elegant than my "magic" flag
in the sense that it requires another explict file operation and that
there's only one flag but perhaps many potential users of that flag,
even for a single file.  My magic flag could maybe be stored in the
per-process file table and thus make it possible for any process to know
when any other process had written to the file.  I don't see any reason
to store this information on the disk either.

However both options are far less elegant than simply fixing the current
assumption that all existing code already has had to live with --
i.e. making true once again the assumption that no file operation is
likely to complete in less time than the interval between timestamp
updates.  Elegant in the sense that one simple fix behind the scenes
will make a whole class of problems simply cease to exist.

Unfortunately nobody's answered my question yet:  Will such a change
adversely affect anything else -- i.e. is it inelegant in other ways?

> It's no more userland code to use than using the st_mtime
> (simply change the time > test to a flag test)

No, not for new applications, but all existing applications would
require changes -- that's what I meant to say when I referred to
"additional coding".

Of course decreasing the granularity of filesystem timestamps would
likely also require a significant number of coding changes in
applications as well; either that or changing the basic assumption of
what 'time_t' represents (eg. increase it to at least 64 bits and change
its resolution to milliseconds).

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