Based on conversation in #41, outputs in --archive-dive and --no-archive-dive modes should come out in a consistent and predictable order.
Current behavior is to follow os.walk with files first then subfolders and not alphabetically. With archive-dive ON, archives are written last so an archive ends up separated from its sibling files.
Conceivably, a user would want outputs sorted on the hash to see identical files grouped together regardless of their location in a collection, but that type of sorting seems more appropriate for downstream use.
This could have implications for parallel hashing (#3), so this should probably be done in coordination with a PR that implements that. The upfront size reporting (part of #33) could also feed the parallel worker task planning so each worker would receive bins of equal 'weight' to hash through.
Based on conversation in #41, outputs in
--archive-diveand--no-archive-divemodes should come out in a consistent and predictable order.Current behavior is to follow
os.walkwith files first then subfolders and not alphabetically. With archive-dive ON, archives are written last so an archive ends up separated from its sibling files.Conceivably, a user would want outputs sorted on the hash to see identical files grouped together regardless of their location in a collection, but that type of sorting seems more appropriate for downstream use.
This could have implications for parallel hashing (#3), so this should probably be done in coordination with a PR that implements that. The upfront size reporting (part of #33) could also feed the parallel worker task planning so each worker would receive bins of equal 'weight' to hash through.