Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > …finds duplicates across large disks instantly

    :D

    by bronlund
  • Reflink conversion would be another nice feature to have. It allows userspace apps to create filesystem-native copy-on-write clones of files, so to the next app they work exactly like another copy of the same data. But the data is on disk only once.
    by Maakuth
  • Interested to know what algorithm you use for --fuzzy. Presumably not any of the worst-case-quadratic diff algorithms... MinHash on n-grams?
    by akoboldfrying
  • I implemented it quite quickly I use SimHash for now but I need to refactor and possibly replace…
    by jdefr89
  • I have a thing like this - one thing I have found useful is also going up the directory tree to find entire duplicated directories. (So dir hash is hash of the concatenation of the subdirs and the files).

    I also used go, it excels at just this sort of thing. Although I saturate the disk to memory bandwidth (for the SHA) way sooner than CPU on my laptop, so it still takes a while to run.

    Nice.

    by lanstin
  • I wrote a tool a short bit ago to handle massive parallel hashing. Originally, it was a testbed for a project I built to make multiprocessing easier in Go.

    https://github.com/indrora/hyperhash

    In it, I learned that there's some interesting quirks about the way the traditional shaXsum tools work, specifically that they focus on a set of inputs from the shell command line, which means that you can exhaust the shell command line length fairly easily (try hashing every file in the Linux source tree, for instance; zsh, bash, and fish will all eventually tell you "Fuck off, there's too many characters in argv")

    I also discovered that Go's handling of file handles varies drastically based on OS. Windows, for instance, has no problem with you taking a file handle to every single file on a disk. Linux will get upset but eventually capitulate, macos will stomp its feet and inform you that you are a bad child and kill you off.

    by indrora
  • Here's a tip, if you are making regular compressed backups of the configuration of your network devices, if you use gzip, make sure to set the mtime to 0 when writing the file as this can throw off deduplication. This also applies to the name field.

    https://docs.python.org/3/library/gzip.html#gzip.GzipFile.mt...

    by chaz6
  • Wow. Wasn’t expecting to see this here… I am the author…
    by jdefr89
  • (Sorry if I missed anything obvious from the documentation)

    Does this work on Windows

    by albert_e
  • Quick question, did you use an LLM to help with this? (Not judging one way or another).

    The only reason I ask is that for the past couple of weeks I’ve been making a similar utility to test out the Sol model and it’s hilarious how similar the architecture and even the CLI switches are to what Codex came up with.

    by ac2u
  • imo fclones is the one to beat, https://github.com/pkolaczk/fclones#benchmarks

    nice that there are actually some ok interfaces here. with fclones, i tend to generate a file of candidates then do a little review to make super certain everything is square / as expected. it's very built for intermediary files a core pattern, which is very unix, very convenient. but it did take me a little while to settle on this, and it felt like i wasn't being offered a ton of options for management out of box. looks like some real attempts to be more user friendly here.

    by jauntywundrkind
  • Do you know if fclones implements anything similar to https://github.com/hpc/libcircle ?

    I also wonder if nftw(3) would be faster than readdir(3).

    by ranger_danger
  • Why do you need a cryptographic hash function for detecting duplicates? xxHash, rapidHash or anything that’s fast will do the job. There’s no need to be secure against inverses.
    by divyekapoor
  • Yeah, long ago I tackled a variant on this--given a directory of files, which ones are already somewhere? I persisted data on what was already there--and found I didn't want to do a good job on the table of what was there. The fastest approach was two tables, the first containing only crc-32s of the files, the second containing more details. Load the first into memory, only load from the second when there was a match on the first. Quickly discarding most prospects was the best route, don't even see if the prospect exists until it passes the first screen.
    by LorenPechtel
  • I'm not sure exactly how it compares, but a similar tool you can use that also does phashes of images/videos to find potential duplicate media files is czkawka [0].

    [0]: https://github.com/qarmin/czkawka

    by psYchotic
  • +1 for Czkawka.
    by qingcharles