Create homebrew package for macOS distribution.

Benchmarks from criterion should be included in the main readme for paq.

Several hashing algorithms were experimented with when prototyping paq.

Ultimately, a consistent and extensible algorithm needs to be chosen and documented in the package README.

Considerations:

• file/directory path hashes
• file/directory metadata hashes
• leaf hash value sorting if tree
• merkle tree hash (bit of future proofing)
• performance/scaling

GIT has been a source of reference for determining how/what to hash.

Make snap available to linux distributions.

Output should be valid JSON with paq in double quotes.

"..."

Prototype of paq was built rapidly as an experiment without tests.

This package shouldn't be considered for real-world use until tests have been added verifying the documented algorithm is functioning as expected.

The tests should function as acceptance criteria / business requirements and use the test host file system (IO).

Running bazel builds in Windows produces directory links (e.g. bazel-bin) that end up an failed reparse point errors from the rust's std library fs:read_link function.

Error:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Uncategorized, message: "Unsupported reparse point type" }', src/lib.rs:69:63
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The bazel build was performed in a docker container using a volume. The container was from a bazel image using linux.

More investigation required in order to support these links.

Rayon is used to parallelize iterating over source paths and hashing file contents; however, if an operating system failure (e.g., locked file) occurs the iterator doesn't immediately fail.

A feature introduced the panic_fuse() function on rayon iterators that terminates iterator threads when a panic occurs leading to a fast failure and ultimately a failed attempt at producing a paq hash but without delay.

There is potentially a near negligible performance degradation that MUST be tested thoroughly if this feature is implemented.

Directory traversal should be refactored to use thread pool rather than walkdir. Pool should perform traversing and hashing at the same time.

Results will be the same since hashes are sorted prior to producing a final hash.

This should improve performance substantially on large file system trees.

Errors aren't handled in the prototype of paq.

Statements potentially resulting in errors need to be identified and respective messaging added.

unix symlink package is a hard dependency in v1.0.0.

Add support to output each hash in the file tree.

Decide whether to use flag to alter default output or to write contents to additional file.

Output should be tab separated hash and path sorted by path.

I needed to know if contents of a folder changed from last time I chcked.

Running first time with errors like this. And it must have taken 4 minutes

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: Uncategorized, message: "The process cannot access the file because it is being used by another process." }', src/lib.rs:79:58
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: Uncategorized, message: "The process cannot access the file because it is being used by another process." }', src/lib.rs:79:58
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: Uncategorized, message: "The process cannot access the file because it is being used by another process." }', src/lib.rs:79:58

Second time round it seems to have taken 1second.. still same errors and niether runs returned a hash

Create windows package distribution.

Dependent on support for windows (nix style paths).

Add a release pipeline that produces binaries for multiple targets.

Rust vector sort_unstable can have better performance than the current sort method.

There will not be duplicate hashes so equal matches will not occur but even if they did it wouldn't affect the combined output hash.