apt/apt-pkg/contrib/fileutl.cc, branch 2.7.2Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.7.22023-03-06T09:57:55ZAddress statements of public domain2023-03-06T09:57:55ZJulian Andres Klodejulian.klode@canonical.com2023-02-27T16:58:33Zurn:sha1:d9039b2409e69e651bf0d7ba582dbf528086332dFix integer underflow in flExtension2022-05-23T08:09:31ZRonan Desplanquesronan.desplanques@gmail.com2022-05-23T07:57:10Zurn:sha1:cacdb54953dbc81eecf4c3a55c132836e7849098
Before this patch, the expression `Res - File.length()` that was
used as the length underflowed. It was very unlikely to cause any
problem given the saturating behavior of the std::string
constructor that's used.
Replacing `Res - File.length()` with `File.length() - Res` would
have worked, but omitting the last argument altogether invokes an
std::string constructor which does the right thing.
RunScripts: Do not reset SIGQUIT and SIGINT to SIG_DFL2021-03-01T20:26:24ZJulian Andres Klodejulian.klode@canonical.com2021-03-01T20:26:24Zurn:sha1:8eccb902aa3be22a151943286fb376759a2b3585
This caused python-apt to unset the Python signal handler when running
update or install commands, breaking KeyboardInterrupt amongst possibly
other things.
We do not set those signal handlers in this functions, and the calling
functions restore signal handlers to previous ones.
LP: #1898026
Use 500 MB memory limit for xz/lzma decoding2021-02-02T18:56:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-02T14:46:34Zurn:sha1:b4b5e9bf97970e0efc4a994de96066a92e3a9b8f
The buffers we feed in and read out are usually a couple kilobytes big
so allowing lzma to use an unlimited amount of memory is easy & okay,
but not needed and confuses memory checkers as it will cause lzma to
malloc a huge chunk of memory (which it will never use).
So lets just use a "big enough" value instead.
In exchange we simplify the decoder calling as we were already using the
auto-variant for xz, so we can just avoid the if-else and let liblzma
decide what it decodes.
Allow prefix to be a complete filename for GetTempFile2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-18T09:55:54Zurn:sha1:c470d92366d7c3c239a689f0a10d6d0d9daafbff
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
Prefer use of O_TMPFILE in GetTempFile if available2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-13T06:42:02Zurn:sha1:37cc8dcda9e97e0b9420d37bb886081fa629847d
Not all filesystems implement this feature in all versions of Linux,
so this open call can fail & we have to fallback to our old method.
GetLock: No strerror if it's just another process holding the lock2020-03-06T12:07:55ZJulian Andres Klodejulian.klode@canonical.com2020-03-06T12:07:55Zurn:sha1:68a83a64cd424385b613f58e23c03e262d840b91
This improves the locking message, getting rid of useless details. If
we have a process holding the lock, we got that because the lock is
being hold by it, so there's no point telling the people the reason
for not getting the lock is the EAGAIN error and displaying its
strerrror().
Raise buffer size for Hashes::AddFD() from 4 KiB to 64 KiB2020-01-14T12:10:36ZJulian Andres Klodejulian.klode@canonical.com2020-01-07T18:55:48Zurn:sha1:b350560e34a369ef7610f9fceeffb00660209390
Move APT_BUFFER_SIZE to macros.h and re-use it in hashes,
this also might speed up stuff, the motivation for using
64 KiB buffers in fileutl.cc was precisely that after all.
Fix some style warnings from cppcheck2019-11-26T11:36:46ZDavid Kalnischkiesdavid@kalnischkies.de2019-09-13T10:01:47Zurn:sha1:35012abf30ec1cfc9b5ee29647d4b1e25d98e99f
Unused variable, std::algorithms instead of raw for-loops.
There should be no observeable difference in behaviour.
Reported-By: cppcheck
Gbp-Dch: Ignore
Improve locking messaging - pid and name, "do not remove lock file"2019-06-21T21:14:46ZJulian Andres Klodejulian.klode@canonical.com2019-06-21T20:45:13Zurn:sha1:cde8399310e56faaa6928411392184bc403eff66
We want to tell users which process is holding the lock so they
can easily understand what's going on, and we want to advise
users not to remove the lock file, because ugh, that's bad.
Re-initalize the flock structure, in case it got mangled by
previous fcntl call.