| Age | Commit message (Collapse) | Author |
|---|
|
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
|
|
|
|
|
|
This patch is a result of auditing all of our uses of
get_datadir_fname() and its kin, and dividing them into cache vs
keys vs other data.
The new get_keydir_fname() and get_cachedir_fname() functions don't
actually do anything new yet.
|
|
|
|
|
|
If we can't read a file because of an FS issue, we say "we can't
read that" and move on. But if we can't read it because it's empty,
because it has no labels, or because its labels are misformatted, we
should remove it.
Fixes bug 24099; bugfix on 0.3.1.1-alpha.
|
|
|
|
Based on questions and comments from dgoulet, I've tried to fill
in the reasoning about why these functions work in the way that they
do, so that it will be easier for future programmers to understand
why this code exists and works the way it does.
|
|
Since we can't be sure that we can unlink enough files on windows
here, let's let the number of permitted entries grow huge if it
really must.
We do this by letting the storagedir hold lots of entries, but still
trying to keep the number of entries under the configured limit. We
also have to tell consdiffmgr not to freak out if it can't actually
remove enough entries.
Part of a fix for bug 22752
|
|
Part of a fix for bug 22752: We can't unlink these because Windows
doesn't allow you to unlink an in-use file.
|
|
|
|
If we're out of file space in the storage directory, we'll need to
get rid of old files fast.
|
|
|
|
This will allow us to have weak references to cache entries.
|
|
|
|
|
|
Every file in the cache is labeled. The labels are held in memory;
the bodies are mapped on demand.
|
