Path: utzoo!attcan!uunet!ginosko!rex!ames!amdahl!drivax!davison
From: davison@drivax.UUCP (Wayne Davison)
Newsgroups: news.software.b
Subject: WARNING! Serious C news bug
Message-ID: <24F5005C.B1B@drivax.UUCP>
Date: 25 Aug 89 08:16:28 GMT
Reply-To: davison@drivax.UUCP (Wayne Davison)
Organization: Digital Research, Monterey CA
Lines: 33

WARNING -- there is a serious problem in the program "updatemin.c" as
released in the 22-Aug patch.  The program leaves the file "active.new"
linked to "active" which causes the next running of updatemin to completely
wipe out your active file (because it creates active.new before reading
any part of active, and since they are linked, active is kaput).

The fix options are simple, the code currently looks like this:

	(void) unlink("active.old");
	if (link("active", "active.old") < 0)
		fail("can't link `active' to `active.old'", "");
	if (unlink("active") < 0)
		fail("can't unlink `active'", "");
	if (link(newname, "active") < 0) {
		if (link("active.old", "active") < 0)
			fail("disaster -- cannot recover `active'!!", "");
		else
			fail("can't link in new `active' -- old one used", "");
	}

One option is to add an unlink(newname) after all this code.  The other
option was in the code I sent them (which bears a very slight resemblance
to the released code) which did a rename(newname,"active") rather than the
unlink("active"), link(newname, "active").  I prefer this method, because
the rename function states that it will delete the destination if necessary,
and that an instance of the destination name will be guaranteed to exist,
even if the system crashes in the middle of the operation.  This saves the
extra recovery steps above and never, in fact, links active to active.new.
The only thing I'm not sure of, is whether rename works this way over the
wide range of OSes out there (I'm running 4.3BSD).  Anyone know for sure?
-- 
Wayne Davison          \  /| / /| \/ /| /(_)         davison@drivax.UUCP
                      (_)/ |/ /\| / / |/  \          ...!amdahl!drivax!davison