Subject: Re: bin/7662: crontab(1) does not always save changed crontab file
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>
From: Ronald Khoo <ronald@demon.net>
List: netbsd-bugs
Date: 06/01/1999 03:45:38
Greg A Woods wrote:

> The only other solution I've ever managed to come up with involves
> adding another file operation (perhaps with fcntl() or similar) to ask
> the kernel if the file has been written to since the last time a given
> process accessed the file.  It seems much less elegant though and
> requires additional user-land coding for every application needing such
> knowledge.

Sounds like the MS-DOG 'Archive flag' which can be set/reset on purpose
and is set by the kernel whenever the file is written.  This gives
precisely the semantics that crontab(1) wants:

	reset flag
	spawn vi
	if (isset(flag))
		commit new crontab

Given that this is a temporary file, it doesn't even conflict with the
primary purpose of the flag which is to facilitate incremental backups
which don't depend upon timestamps either.

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.

It doesn't cost anything to implement (you're going to write the inode
with the mtime anyway)

It has the additional cachet of MS-DOS compatibility :-)

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

So, apart from the fact that we don't have this particular flag,
anything wrong with it ?

--