Re^5: HTTPD-Password Self-Management and Recovery

That will not work.

Consider the following:

Process A wants to change the pasword file: it copies the password file to newfile-A.
Process A does its edits on newfile-A
Process B wants to change the pasword file: it copies the password file to newfile-B.
Process A renames newfile-A to password file.
Process B does its edits on newfile-B
Process B renames newfile-B to password file.

Now process A's edits are wiped out.

Next to the atomic rename opeation, you will need file-locking too: but that means only one writer is allowed at the same time, hence unavailability of the server for all those waiting for the lock to be released.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Comment on Re^5: HTTPD-Password Self-Management and Recovery

Replies are listed 'Best First'.
Re^6: HTTPD-Password Self-Management and Recovery by mhi (Friar) on Dec 04, 2011 at 19:01 UTC
What you are describing here is the so-called lost-update problem. This can be avoided by using file-locking as you correctly pointed out. File locking does not make the server unavailable (for reading the old file) as long as you only use a write-lock and not a read-lock. A write-lock is completely sufficient in this case. Edit: The reason I don't intend to do a database-centered login is that I would actually like not to add a database and to separate the authentication from the application.	[reply]
Re^7: HTTPD-Password Self-Management and Recovery by CountZero (Bishop) on Dec 04, 2011 at 20:54 UTC
A write lock will block a second "recover password" attempt when the first one is running and has not yet released the lock. I grant you that it is probably an unlikely event, but still ... CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]