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].
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.
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.
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.
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.
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.
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.
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.
> 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")
Did you try to run something like
sha256sum **/*.*
Because if so, then you'll of course exceed the maximum number of arguments. That applies to all command-line tools that take an unbounded number of arguments.
A simple solution is to use find, which handles that for you:
find -type f -exec sha256sum "{}" "+" # 1.4s on my system for Linux 7.1.5
Alternatively, you can combine find with xargs (or parallel), which also handles it and optionally allows you to specify exactly how many arguments to process per call (-n), and how many commands to run in parallel (-P):
I always have all these parallel things take a configurable number of worker go routines, then try different numbers and run btop or iostat to see how close I am to being hardware bound. Never had a machine where the limit was anywhere close to the number of open FDs allowed. I guess I haven't proven this but my idea is having the generic scheduler have to sort 60k FDs or 2M (I have a lot of dup files in my "backup everything, randomly and repeatedly, since 1998 file system) FDs is going to thrash stuff more than just having go's runtime and my own code.
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.
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.
[0]: https://github.com/qarmin/czkawka