| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Sponsored-by: author
|
|
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
|
|
Sponsored-by: author
|
|
This type was superceded by fsentry::FsEntryError in
a2adcb5a90c15b473a2fcf114555443fba8a20ce.
Fixes #183.
|
|
Also, make it an error for a public symbol to not be documented.
Sponsored-by: author
|
|
For chmod() we need to cast mode parameter from u32 to u16 because
MacOS has 16 bit mode_t while Linux is using 32 bits.
|
|
|
|
All unclear error messages should now be clearer. For example, all the
ones related to a file mention the file name and the attempted
operation that failed.
|
|
|
|
Actually, these aren't yet actually stored in the backup. That will
happen when there's a way to verify file metadata stored in the
backup. But this adds the code to look up the data during a backup so
that at least that part gets some exercise.
|
|
|
|
|
|
This means that a function that parses step bindings can't return an
error that the document is missing a title. Such an error return would
be nonsensical, and we use the Rust type system to prevent it, at a
small cost of being a bit verbose.
Additional benefit is that the library portion of Obnam doesn't return
anyhow::Result values anymore.
|
|
This uses the previous, latest generation as a guideline to see what
is new or changed.
|
|
This is the most generic way to store filenames.
|
|
This is a step towards changing how filenames are stored in FileSystemEntry.
|
|
|
|
|
|
|
|
|
|
Now from a Metadata struct, instead of a bunch of field values. The
justification for this is that callers shouldn't have to unpack a
Metadata, especially since it'll be different for each operating
system in the future. Keep all that in one place instead.
|
|
This avoids having to add extra columns when we add more metadata
support. This may be worth re-thinking later, once things stabilize.
|
|
|
|
|
