1. 15 May, 2022 2 commits
  2. 10 May, 2022 1 commit
  3. 03 May, 2022 4 commits
    • Lars Wirzenius's avatar
      refactor: add a builder for file system entries · 49133472
      Lars Wirzenius authored
      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
    • Lars Wirzenius's avatar
      test: add test for storing, retrieving u64::MAX values in JSON · 3d50e149
      Lars Wirzenius authored
      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
    • Lars Wirzenius's avatar
      feat! only store signed 64-bit plain integers in database · 856d32c4
      Lars Wirzenius authored
      This is a breaking change, but allows to store the largest signed
      64-bit integers in SQLite and get it back.
      Sponsored-by: author
    • Lars Wirzenius's avatar
      refactor: add a type for plain integers we store in a database · aad50a08
      Lars Wirzenius authored
      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
  4. 22 Apr, 2022 2 commits
  5. 21 Apr, 2022 3 commits
  6. 19 Apr, 2022 1 commit
  7. 16 Apr, 2022 4 commits
    • Lars Wirzenius's avatar
      feat: use one checksum for all chunks in a backup · 18c0f4af
      Lars Wirzenius authored
      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
    • Lars Wirzenius's avatar
      feat! change how chunk labels are serialized · 82ff782f
      Lars Wirzenius authored
      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
    • Lars Wirzenius's avatar
      refactor: rename Checksum to Label · d9b72ffa
      Lars Wirzenius authored
      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
    • Lars Wirzenius's avatar
      refactor: add a Literal variant to Checksum · 9f6ff22f
      Lars Wirzenius authored
      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
  8. 07 Apr, 2022 1 commit
  9. 06 Apr, 2022 2 commits
  10. 05 Apr, 2022 2 commits
  11. 29 Mar, 2022 1 commit
  12. 28 Mar, 2022 1 commit
  13. 23 Mar, 2022 1 commit
  14. 22 Mar, 2022 5 commits
  15. 20 Mar, 2022 7 commits
  16. 14 Mar, 2022 2 commits
  17. 13 Mar, 2022 1 commit