ok, you should _Definitely_ examine lib/util_file.c in the samba source, and how it is used to update smbpasswd. i believe that the problems we faced and solved with smbpasswd are exactly those you are describing here. On Wed, 30 Aug 2000, Cooper wrote: > Michael Tokarev wrote: > > > > But wait -- one big issue with this exists. Note that > > "dotlock" file created before opening real /etc/passwd file, > > and it does _not_ removed after use. But applications that > > updates /etc/passwd need to have reliable way to change > > contents of that file, that is typically implemented by > > creating new file and issuing two rename()s. > > I feel I'm starting to lose track here, so am I right in assuming you > rename passwd to something else (passwd.old) and then the new thing to > the new passwd? > > > With this, > > it is hard to ensure that second app that waits for a lock > > will use correct /etc/passwd when first lock released, not > > a file that was renamed by first app. > > Correct. Which I think is exactly why you shouldn't use a second file > when you try to lock a file. When you rename a new file to the current > name, anybody who has the current file open will basically be using old > data once the rename is complete. If that old data was used as a > starting point for a modification the fun can begin.
