On Tue, 27 Jan 2009 22:21:06 +0100, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> --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. Precisely, The only purpose of the rename() function (or system call) is to guarantee that when a new file replaces an old file, the name of the old file will not be lost; the name will either refer to the old file or to the new file. The intent of this operation relative to applications updating existing files was stated when rename() was first introduced as a separate system call: A Fast File System for UNIX* Marshall Kirk McKusick, William N. Joy , Samuel J.Leffler!, Robert S. Fabry Revised February 18, 1984 5.4. Rename Programs that create a new version of an existing file typically create the new version as a temporary file and then rename the temporary file with the name of the target file. In the old UNIX file system renam-ing required three calls to the system. If a program were interrupted or the system crashed between these calls, the target file could be left with only its temporary name. To eliminate this possibility the rename system call has been added. The rename call does the rename operation in a fashion that guarantees the existence of the target name. --- frankB
