diff options
author | David Kalnischkies <david@kalnischkies.de> | 2016-03-06 12:03:34 +0100 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2016-03-06 12:57:38 +0100 |
commit | dfcf7f356b790338f0a3e9df3c5d6f159814fe53 (patch) | |
tree | ce6b16a51fceca130eb6097b986581188ccdeb9e /debian/source | |
parent | 9a63c3f480bcbc3232067237671b854d43a97236 (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 'debian/source')
0 files changed, 0 insertions, 0 deletions