On Fri, Jul 27, 2012 at 10:28:08AM +0200, Bastian Blank wrote: > On Thu, Jul 26, 2012 at 11:53:25PM -0700, Ben Pfaff wrote: > > On Fri, Jul 27, 2012 at 08:39:42AM +0200, Bastian Blank wrote: > > > I would always use the lock file at the target location of the database > > > and not follow symlinks there. Otherwise more than one lock file can > > > exist. > > We have to follow symlinks, so that the lock file ends up in /var/lib, > > because FHS says that /etc is static, and therefore may be mounted > > read-only, and therefore we cannot create a read/write file there. > > I was unclear. You should first use realpath(3) on the database filename > and calculate the lock file from there. Otherwise there may be several > lock files for the same db.
No. We create a symlink for the lock file. There is only one lock file, at the target of the symlink. > Also, I see no lstat or realpath calls, so using symlinks is not safe > anyway. The daemon does not know the real location to calculate the lock > and temp file locations. It does not need to calculate the real location, because there is a symlink for the database file and a symlink for the lock file. > > > On second thought, drop the lock file and use fcntl(db, F_SETLK…) on the > > > database file itself. This lock is automatically released if the process > > > dies. > > We cannot drop the lock file, because the lock file grants the right not > > merely to modify the database but to put another file in its place. > > That is, the locked entity is the name, not the inode to which the name > > refers. > > This is no real problem. Obtaining an exclusive lock for the complete > file, not only parts, may include the right to replace it. This just > needs to be documented. Locking is an implementation detail. There is no need to document it. You may be correct that it is possible to use a lock on the database file, instead of separate database and lock files. I have not thought about the problem recently. However, this locking design is over three years old, it works reliably, and I am not going to replace it on a "long term stable" branch that we branched off in 2011 unless it has serious problems that cannot be fixed less disruptively. > However the current solution alows for a disappearing lock file and > may corrupt the database in this case. The lock file is never deleted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
