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. > With this, "dotlock" method is far more reliable when > locking of /etc/passwd itself (recall -- dotlock _never_ > removed). Method used by util-linux (?) (creating > passwd.lck and shadow.lck) is less reliable, but > lckpwdf()'s one (creating /etc/.pwd.lock) is a best. I totally fail to see the apparently obvious advantage of having a lock file with a different name. When using a lock on the file itself, you're in the clear unless you want to replace the file in question with a different file. Since a file needs to be opened *BEFORE* you can acquire a POSIX lock, you need to stick to that one file which can be considered a disadvantage. If you want to add to the passwd file the POSIX lock will do. You lock, append, if that fails ftruncate back to the old size and it seems as if nothing happened. If you want to delete from the passwd file, you could use a POSIX lock. You lock, read, delete the line from the read data, write the data back to the file starting at filepos 0 and truncate whatever space is left. Problems arise when you want to update a line. It can be done with a POSIX lock too, but is more complicated. You lock, read, take out but locally store the line, write the remainder starting at pos 0, update the locally stored line in another location, write that at the current position of the file and if that were to fail you truncate back to that position and write the old line instead. This approach will work as long as nobody pulls the plug on the machine during the writes, which is really the only drawback of this approach. If that were to happen (enter Mr. Murphy) the potential is that lines get clobbered and that is, particularly with these files, totally unacceptable. To counter this the update and delete could simply blank out the line in the file and in the case of an update simply append to the end of the file. This will make a mess of the passwd file though. Bottom line, considering all this above (hope you'll excuse my think-as-I-type message) POSIX locks alone seem inadequate for this application. Still curious to see how the "dotlock" file thing solves the problem... Best I can tell it moves the problem to the lockfile, but doesn't remove it... Cooper -- If you can read this you're probably not dead yet. - Johnny The Homicidal Maniac 7 -
