The key argument being sent to hashindex_get and hashindex_set by
multiple functions is a different signedness from what the functions
expect. This resolves the issue by changing the key type in the
unpack_user struct to unsigned char.
The value argument of hashindex_set is causing harmless pointer type
mismatches. This resolves the issue by changing the type to void*
which silences these types of warnings.
This resolves a compiler warning from the generated code that
resulted from a comparison of two local variables of different
signedness. The issue is resolved by changing the type of both
to int since this seems like the safest choice available.
The generated source code was producing a compiler warning due to
the pointers differing in constness. The called function expects
a non-const pointer while the generated code produces a const pointer
via a cast. This changes the cast to drop 'const' to make the compiler
happy.
Thanks to Andrey Bienkowski (@hexagonrecursion) for reporting this and writing reproducer code.
Changes:
- use different, randomly (but recognizably) named temp files while writing (securely made by os.mkstemp())
- make sure temp files are cleaned up in normal and error conditions
- SyncFile can now get corresponding pair of path + open os-level fd
- cleaned up: fd now means os-level fd, f means python-file-like object
- fixed a caller of SaveFile
first time borg info is invoked on a borg 1.1 repo, it can take
a rather long time computing and caching some stats values for
1.1 archives, which borg 1.2 archives have in their archive
metadata structure. be patient, esp. if you have lots of old
archives.
following invocations are much faster.
the .get() like behaviour (== returning the value) was missing.
it's still not 100% like dict.setdefault, because there is no
default value None. but None doesn't make sense here, because we
usually need a N-tuple matching the hash table's value format.
note: this "bug" (or unusual implementation) was without consequences,
because hashindex.setdefault is not used anywhere in borg, so
it was also not used in a wrong way anywhere.
https://docs.python.org/3/library/stdtypes.html#dict.setdefault
docs:borg init: explain the encryption modes better
The documentation for borg init was not structured logically:
1. The topic is switched from the general discussion of `borg init`
to the discussion of encryption modes without a title.
2. Obscure technical details (chunking, id generation etc) were
above the high-level overview and other key information.
I am about to add documentation for this feature. Per the "If you liked
it, you should have put a CI test on it" rule I am adding tests to
detect if the feature regresses (causing a discrepancy between the docs
and the real behavior).
If we create a new repo (and a new keyfile key, create=True),
there must not already exist a keyfile at the path/filename
where we want to write the new one.
In other use cases (e.g. if we overwrite a keyfile due
to the user changing their passphrase, create=False),
of course overwriting at the same path/fname is desired.
compact_segments produced separate 17b files for intermediate commits, although they were intended to be end-of-segment-file commits.
this is because when the intermediate commit is triggered, we are already at an offset beyond the limit.
thus needed to add the no_new flag to indicate that we do not want a new segment file just for the commit IF it is an intermediate commit.
- use expanded location for log output
- support placeholder expansion for BORG_REPO env var
- use Location.raw for the unprocessed, not expanded location string
https://github.com/borgbackup/borg/pull/6186#issuecomment-1023504905
> could you rename the strip test a little, so that there is
> ..._remote_repo in the test name. if one does not fully read the test
> (like me), one would assume that a strip-related test also applies to
> local repos, but in this case, the condition checked only applies to
> remote repos.
