Age | Commit message (Collapse) | Author | Files | Lines |
|
Sponsored-by: author
|
|
add tests for storing max integers (change FileId to signed)
Closes #188
See merge request obnam/obnam!231
|
|
The previous commit introduced a function to create FilesystemEntry
values from arbitrary data. Previously one could only be created from
std::fs::Metadata. This complicated our own testing, which (now) needs
to construct an arbitrary entry structure. However, while the function
added in the last commit was straightforward, it had 11 arguments, and
that's hard to keep track of. Replace that function with an
EntryBuilder struct, for clarity.
Sponsored-by: author
|
|
The test passes. We create a FilesystemEntry with a length field
containing u64::MAX, store that into a generation, and read it back.
This works. The entry is serialised into JSON for storing in SQLite,
and this proves we can handle any u64 value in an entry. serde_json
deals with it fine, and we don't need to worry about it.
Sponsored-by: author
|
|
This is a breaking change, but allows to store the largest signed
64-bit integers in SQLite and get it back.
Sponsored-by: author
|
|
This will make it easier to change later, if need be. We may want to
do that for various reasons, such as to save space. We may also want
to change things to only use integer types that SQLite can handle: u64
is currently not well handled by our database layer. However, as this
is a refactor, there's no change or fix to that.
FileId is now explicitly a database integer. This doesn't break
anything, for now, as the underlying integer type is still u64.
Also, change a couple of places where it will matter if DbInt changes
away from u64, and disable warnings for harmless conversions that
may cause warnings depending on what type DbInt has.
Sponsored-by: author
|
|
show SQLite file size
Closes #29
See merge request obnam/obnam!230
|
|
docs: add a note of why CACHEDIR.TAG itself gets backed up
Closes #190
See merge request obnam/obnam!229
|
|
Sponsored-by: author
|
|
This is more friendly towards anyone wanting to use the output in a script.
Sponsored-by: author
|
|
Sponsored-by: author
|
|
add support for migrating to new checksum types
Closes #203
See merge request obnam/obnam!228
|
|
When making a backup, use the same checksum for any chunks it re-uses
or creates. This is for performance: if we allowed two checksums to be
used, we would have to compute the checksum for a chunk twice, and
potentially look up both on the server. This is just a lot of work.
Instead, we use only one. The trade-off here is that when (not if) the
user wants to switch to a new checksum type, they'll have to do a full
backup, uploading all their data to the server, even when it's already
there, just with a different checksum. Hopefully this will be rare.
Full backups always use the built-in, hardcoded default checksum, and
incremental backups use whatever the previous backup used. The default
is still SHA256, but this commit add code to support BLAKE2 if we
decide to switch that as a default. It's also easy to add support for
others, now. BLAKE2 was added to verify that Obnam can actually handle
the checksum changing (manual test: not in the test suite).
I don't think users need to be offered even the option of choosing a
checksum algorithm to use. When one cares about both security and
performance, choosing a checksum requires specialist, expert
knowledge. Obnam developers should choose the default. Giving users a
knob they can twiddle just makes it that much harder to configure and
use Obnam. If the choice Obnam developers have made is shown to be
sub-optimal, it seems better to change the default for everyone,
rather than hope that every user changes their configuration to gain
the benefit.
Experience has shown that people mostly don't change the default
configuration, and that they are especially bad at choosing well when
security is a concern.
(Obnam is free software. Expert users can choose their checksum by
changing the source code. I'm not fundamentally limiting anyone's
freedom or choice here.)
Users can switch to a new default algorithm by triggering a full
backup with the new "obnam backup --full".
Sponsored-by: author
|
|
Serialized labels now start with a type prefix: a character that says
what type of label it is.
This isn't strictly required: we _can_ just decide to always use a
single type of checksum for all chunks in one backup, for one client,
or in the whole repository. However, if it's ever possible to have
more than one type, it helps debugging if every checksum, when
serialized, is explicit about its type.
Change things to use the new serialize method instead of the Display
trait for Label. We're primarily serializing labels so they can be
stored in a database, and used in URLs, only secondarily showing them
to users.
Sponsored-by: author
|
|
Label is a clearer and more accurate name for the type now that it is
not just a checksum.
Also, serialize a Label in tests, rather than using string literals.
This is more correct, and we'll be changing serialization later.
Sponsored-by: author
|
|
We've had fake checksums that are just arbitrary literal strings, and
this change makes this more explicit. It's a preliminary change for
later support for additional checksum algorithms.
Sponsored-by: author
|
|
feat! add chunk server API version to HTTP paths
Closes #202
See merge request obnam/obnam!227
|
|
What was /chunks is now /v1/chunks. This is the minimal step to start
supporting multiple API versions.
Also, /v1/chunks/foo/bar is no longer supported.
Sponsored-by: author
|
|
Log some performance measurements
Closes #174
See merge request obnam/obnam!226
|
|
Log the complete run-time of the program, and the time spent
downloading the previous generation, and uploading the new generation.
Sponsored-by: author
|
|
Sponsored-by: author
|
|
Remove debug prints
See merge request obnam/obnam!225
|
|
|
|
Add chunk that lists all generations
Closes #62 and #34
See merge request obnam/obnam!224
|
|
Sponsored-by: author
|
|
Sponsored-by: author
|
|
Backups made with this version can't be restored with old clients, and
vice version.
Sponsored-by: author
|
|
Sponsored-by: author
|
|
add backup database schema to evolove; break server database
Closes #194 and #192
See merge request obnam/obnam!222
|
|
Sponsored-by: author
|
|
Sponsored-by: author
|
|
Sponsored-by: author
|
|
The way this is currently implemented resulted in a lot of code
duplication in src/generation.rs. This should be refactored later. My
first attempt to do it by adding a trait for a schema variant failed.
Sponsored-by: author
|
|
For clarity, though these aren't yet used anywhere. That will happen soon.
Sponsored-by: author
|
|
fix: URL to source code repository
Closes #187
See merge request obnam/obnam!223
|
|
Sponsored-by: author
|
|
docs: update the file metadata description
Closes #19
See merge request obnam/obnam!221
|
|
feat! rename metadata field "sha256" to "label"
See merge request obnam/obnam!220
|
|
Sponsored-by: author
|
|
The field still contains a cleartext SHa256 of the cleartext chunk
data, but this makes it clearer that it may contain other data.
This is a breaking change: the server API won't work with an old
client, and the new client won't work with an old server. To avoid the
breakage would require more effort than is warranted at this time,
given the very small number of users of Obnam. Sorry.
Sponsored-by: author
|
|
chore: cargo update
See merge request obnam/obnam!219
|
|
|
|
update dependencies
See merge request obnam/obnam!218
|
|
"cargo update" doesn't do that automatically, as it's a minor version
bump, from 0.26 to 0.27.
Sponsored-by: author
|
|
Sponsored-by: author
|
|
docs: add benchmark result update to RELEASE.md
See merge request obnam/obnam!217
|
|
Sponsored-by: author
|
|
chore: update for release 0.7.1
See merge request obnam/obnam!216
|
|
Sponsored-by: author
|
|
speed up backups
See merge request obnam/obnam!215
|