On Fri, Jul 27, 2012 at 11:39:47PM +0200, Bastian Blank wrote:
> On Fri, Jul 27, 2012 at 10:21:10AM -0700, Ben Pfaff wrote:
> > On Fri, Jul 27, 2012 at 10:28:08AM +0200, Bastian Blank wrote:
> > > 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.
>
> If it is a symlink, several lock files may exist.
Can you give an example?
> > > 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.
>
> And how does compating the db work if the process does not know the real
> location? rename(2) overwrites symlinks not the target.
Good point. I sent out a series of additional patches to fix this,
which you can find starting here:
http://openvswitch.org/pipermail/dev/2012-July/019730.html
Using realpath would be a mistake, though, since it only works with
symlinks whose targets exist, but I don't want to make that
assumption.
> > > 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.
>
> If you expect locking, it is not longer implementation detail but part
> of the spec. Otherwise locking is optional.
I know of exactly two programs that need to know the locking details.
Both of them are part of the OVS distribution. If someone writes a
third program, that is not part of the OVS distribution, then I'll
happily coordinate with him or her.
> > > However the current solution alows for a disappearing lock file and
> > > may corrupt the database in this case.
> > The lock file is never deleted.
>
> You are working on a real, not a perfect system. Stuff can disappear by
> the hand of the admin, especially if it is empty and apperantly unused.
> And this does not get better with this symlink stunt.
An admin should not delete files because he doesn't recognize their
purpose.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
