On Mon, 2011-10-10 at 15:05:31 +0200, Raphael Hertzog wrote:
> On Sat, 24 Sep 2011, James Vega wrote:
> > dpkg-gencontrol generates a tempfile, debian/files.new, and then
> > attempts to rename that back to debian/files when it's done generating
> > the files.new. This can easily break when parallel builds are happening
> > as independent dpkg-gencontrol runs may rename files.new out from
> > underneath each other. This happened in a recent build of the Vim
> > package[0].
>
> I wonder what's the best way to fix this. Using flock() on
> debian/files.new is not really enough since the file is renamed
> at the end of the process.
>
> Ideally we should use a persistent debian/files.lck that can be safely
> flock()ed but this temporary file would not be cleaned by any current
> package, meaning that it would lead to cruft in source packages.
>
> The cleanest approach I see is to try to lock the file in a loop
> until the file is still here (meaning there was no contention and thus
> no other instance that dropped the file after we opened it and while we
> were waiting for the lock):
>
> while (1) {
> open(LOCK, ">>", "debian/files.lck");
> flock(LOCK, LOCK_EX);
> last if -e "debian/files.lck";
> close(LOCK);
> }
> # Put code updating debian/files here
> unlink("debian/files.lck");
> flock(LOCK, LOCK_UN);
> close(LOCK);
> Does anyone see possible problems with this approach? Or has anyone
> something cleaner to suggest?
This is inherently racy, if a process A is modifying the file, and
process B waiting on the lock, when A removes the file, a process C
could create and lock a new file, which would not share the lock with
B, and both C and B would proceed to stomp on each other. In addition
this might not support NFS on some systems.
The correct solution would be to lock a file we know must be there, so
that there's no race condition and no possible cruft leftover. For
example debian/control or debian/changelog (or the file arguments
specified on the command line). Also we should be using fcntl(2)
instead of flock(2) to get NFS support, but this seems tricky on perl?
> Would it make sense to factorize the logic above in 2 functions
> in Dpkg::Path?
I guess it depends on the complexity of the stuff we end up with.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
