consider it a exit failure if it doesn't work. This means that root
processes can safely get the lock, but normal processes can still use
the 'pw' utility to get information (which may change out from under
them.)
from PR/6787, but allow non-root users to use pw to get password
information. However, this should be safe since the fixes for
disallowing multiple instances from modifying the DB are still intact.
Bug noted by: dima@best.net (Dima Ruban)
run at the same time.
Notes:
The fileupdate function is still somewhat broken. Instead of
returning a failure code if it can't modify the original file it
renames the .new file and continues as though nothing is wrong.
This will cause the lock on the original file to be lost and could
lead to a similar race condition. I left that portion of the code
alone since I feel that the maintainer of the code would have a
better concept of how he wants to handle errors in that function
than I do.
PR: bin/6787
Submitted by: Craig Spannring <cts@internetcds.com>
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
sysinstall's new User&group menu will use it, hence it's a 2.2
candidate despite of providing new functionality.
Submitted by: David L. Nugent, <davidn@blaze.net.au>
