[fix] Filesystem path: hash function not robust enough #129
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
blefaudeux
force-pushed
the
ben/filename_hash_not_robust_enough
branch
from
f77a4cf to
f0c8928
Compare
photoroman
approved these changes
Jun 12, 2025
|
jeez, on the agents there's no HW random source probably, so ahash falls back to another path which is actually less random -> the test now fails (: https://docs.rs/ahash/latest/ahash/ having a look |
|
woops, looks like fasthash is causing trouble to the CI.. having a look later, a bit short at the moment |
|
still not good enough, cc @photoroman https://github.com/Photoroom/datago/actions/runs/15634295340/job/44045572960 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
lucky catch, a unit test failed on me and I had to investigate.. the hashing function was not good enough and sequential filenames could all end up in the same bucket (for 10 consecutive files, something like 10% of the time)
Fixed by using a better hashing function