Fix bug 11567 updxlrator: don't prematurely release lock file
authorJustin Luth <justin_luth@sil.org>
Sat, 30 Dec 2017 06:25:50 +0000 (09:25 +0300)
committerMichael Tremer <michael.tremer@ipfire.org>
Sun, 7 Jan 2018 19:49:53 +0000 (19:49 +0000)
commite04f86b4490c2f22c93fd1fdf9ae5d06971b8581
tree8c004f526be3231630e3a6651bb1e0e8a1104eea
parente331e22bda26e53cd71d04e43d4d8a9d9306b51e
Fix bug 11567 updxlrator: don't prematurely release lock file

With Microsoft's new style of downloading updates,
where portions of a patch are requested multiple times per second,
it has become extremely common for downloads to reach > 100%.
Due to an early unlinking of the "lock" file, there is a big window of
opportunity (between the unlink and wget actually saving some data)
for multiple download/wget threads to start, adding to the same file.
So not only is bandwidth wasted by duplicate downloads running
simultaneously, but the resulting file is corrupt anyway.

The problem is noticed more often by low bandwidth users
(who need the benefits of updxlrator the most)
because then wget's latency is even longer, creating
a very wide window of opportunity.

Ultimately, this needs something like "flock", where the
file is set and tested in one operation. But for now,
settle with the current test / create lock solution, and
just stop unnecessarily releasing the lock.

Since the file already exists as a lock when wget starts,
wget now must ALWAYS run with --continue, which
works fine on a zero-sized file.

Signed-off-by: Justin Luth <jluth@mail.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
config/updxlrator/download