--On Tuesday, January 27, 2009 08:05:45 AM -0800 Frank Batschulat <Frank.Batschulat at Sun.COM> wrote:
>> This bug, 6793488, has been created recently for a >> case I have open with Sun Support. This is a very >> severe case to me and my customer. I would like to >> get it fixed as quickly as possible. I was told the >> bug was dictating this case, which in turn, affects >> the priority of my case being resolved. If this >> affects others please add comments to this post. If >> an engineer can also help it would be greatly >> appreciated. Another bug similar to this one is >> 6571565. Here are the links: >> >> http://bugs.opensolaris.org/view_bug.do?bug_id=6793488 > > Hey Josh, by accident I run across your posting. Since I'm the engineer > who closed this bug as not a bug I'd like to share my reasoning with you > that I've put into the bugs evaluation that is not visible to you. I hope > this helps you to better understand the issue and overall picture. > > This is not a bug (tm), it is not a bug in lofs(7FS), not in ufs(7FS) > and not in mv(1) either. Yup; the behavior described is how it's supposed to work. The key fact that the submitter of 6793488 seems to have figured out but others may not is that commands which update the passwd file do so by creating a new file, then renaming it on top of the old one. The contents of the original file are not changed. This is important because renaming a new file on top of the old one is an atomic operation, while rewriting the contents is not. If the file is rewritten, then there are points in time when another process looking at it may see something other than the old or new contents, such as only the first few lines of the new contents (that is assuming the rewrite is done with O_TRUNC; otherwise the results could be even worse). Further, if the system or even just the passwd command were to crash during the rewrite, it's possible the file could be permanently broken in that way. That would be Very Bad(tm). A rename doesn't have either of these problems, which is why it's done that way. Note that this means that the workaround suggested in the bug report is a poor one, because it has the same non-atomic behavior. -- Jeff
