© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
First it would be nice to have a feeling about the magnitude of this problem. The situation you describes above will only (as far as I can see) when:
1) FirefoxA "forgets" to drop its lock, when it is done updating the file.
or
2) When a user actually are using several different physical terminals at the same time.
1) Would be a bug.. 2) might happen but the locks should only be held while doing changes to the files, so even here, the chanches of a "collision" is fairly rare.
By checking ctime on the files, other firefox instances may be able to look for changes in the files done by others.
Example code could be SQLite3 that supports running different processes updating and accessing the same file, safely changing them under concurrent load. (They have a big nice warning about broken NFS-locking on their webpage). Gnome seems to rely on NFS-filelocking that works, but given the number of NFS-servers and clients out there, there may be broken combination among. (but that is not really firefox's problem).
Jesper