| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Adapted from https://github.com/BLAKE3-team/BLAKE3/pull/430/
by dbohdan.
|
|
|
|
Fixes #222.
|
|
|
|
|
|
This matches what md5sum does.
|
|
Add a warning to stderr at the end similar to other *sum utilities when --check is used and some files failed verification.
At least the last part of the comment above check_one_checkfile seemed to be incorrect so I removed that comment.
Fixes #283
|
|
|
|
|
|
This was previously there, but got dropped in
c5c07bb337d0af7522666d05308aaf24eef3709c.
|
|
|
|
|
|
Suggested by @llowrey:
https://github.com/BLAKE3-team/BLAKE3/issues/33#issuecomment-629853747
|
|
|
|
This is an overall cleanup of everything that b3sum is doing, especially
file opening and memory mapping, which makes it easier for the regular
hashing mode to share code with the checking mode.
|
|
|
|
As part of this, reorganize b3sum tests into src/unit_tests.rs and
tests/cli_tests.rs.
|
|
Rather than breaking the check parse with more output, we'll have a rule
that a Unicode replacement character (�) in a path name automatically
fails the check.
|
|
As proposed in
https://github.com/BLAKE3-team/BLAKE3/issues/33#issuecomment-623153164
This brings b3sum behavior close to md5sum. All occurrences of backslash
are replaced with "\\", and all occurrences of (Unix) newline are
replaced with "\n". In addition, any line containing these escapes has a
single "\" prepended to the front.
Filepaths were already being converted to UTF-8 with to_string_lossy(),
but this commit adds an extra warning when that conversion is in fact
lossy (because the path is not valid Unicode). This new warning is
printed to stdout, with the goal of deliberately breaking --check (which
is not yet implemented) in this case.
|
|
Using mmap is not always the best option. For instance, if the file is
truncated while being read, b3sum will receive a SIGBUS and abort.
Follow ripgrep's lead and add a --no-mmap option to disable mmap. This
can also help benchmark the mmap versus the read path, and help debug
performance issues potentially caused by mmap access patterns (like
issue #32).
|
|
|
|
|
|
|
|
|
|
The previous version of this API called for a key of exactly 256 bits.
That's good for optimal performance, but it would mean losing the
use-with-other-algorithms property for applications whose input keys are
a different size. There's no way for an abstraction over the previous
version to provide reliable domain separation for the "extract" step.
|
|
Putting secret keys on the command line is bad practice, because command
line args are usually globally visible within the OS. Even if these
flags are mostly intended for testing and experimentation, we might as
well do the right thing. Plus this saves people the trouble of hex
encoding their keys.
|
|
|
