summaryrefslogtreecommitdiff
path: root/README.progress-reporting
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-03-06 12:03:34 +0100
committerDavid Kalnischkies <david@kalnischkies.de>2016-03-06 12:57:38 +0100
commitdfcf7f356b790338f0a3e9df3c5d6f159814fe53 (patch)
treece6b16a51fceca130eb6097b986581188ccdeb9e /README.progress-reporting
parent9a63c3f480bcbc3232067237671b854d43a97236 (diff)
do not move not-failed pdiff-patches into CWD on failure
If a single pdiff fails, we have to fail the entire patching endeavour and fall back to getting the complete file instead. That is easy in serverside merged pdiffs as we get them one by one. For clientside we get them all at once through, which means that a failure in one has to stop the entire pipeline, which works as expected (as proven by the bugreporters as they don't even notice it happening). The problem is just that the first failing pdiff will do the cleanup, so another pdiff which happens to be successfully acquired after we processed the failure doesn't find the file it is supposed to use as a basename anymore, so the patch is renamed to what should be the unique extension and moved into the current working directory. Processing is then stopped as the patch realizes that it isn't the last one which completed downloading. On the plus side this means this is neither us using a bad temporary location nor a security problem. It "just" overrides unconditionally files in your current working directory (if you happen to have them named like a pdiff patch – a bit unlikely perhaps) and so drops files there which are never used again. I guess this was introduced in 4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e for real as I made the need for the existence of the base file rather explicit, but the potential lingers in the code for far longer. Closes: #816837
Diffstat (limited to 'README.progress-reporting')
0 files changed, 0 insertions, 0 deletions