If you don’t mind CLI tools, You can try dedup - https://github.com/ttkb-oss/dedup . Use the —-dry-run option to get a list of files that would be merged without modifying anything and how much space would be saved.

On good file systems (see <https://news.ycombinator.com/item?id=43174685>) also identical chunks of files can be merged, resulting in more savings than with just whole files. As of now, dedup cannot help with this, but duperemove or jdupes do.

Yeah, not having an extent API or even an API that can clone to a file descriptor is unfortunate.

That said, keeping track of blocks and extents for deduplication would be a much more expensive problem to solve.

I'll check it out! Thanks!

This reminds me -

Back in the MS-DOS days, when the RAM was sparse, there was a class of so-called "memory optimization" programs. They all inevitably found at least few KB to be reclaimed through their magic even if the same optimizer was run back to back with itself and allowed to "optimize" things. That is, on each run they always find extra memory to be freed. They ultimately did nothing but claim they did the work. Must've sold pretty well nonetheless.

>Back in the MS-DOS days, when the RAM was sparse, there was a class of so-called "memory optimization" programs

You may find this interesting: Investigations into SoftRAM 95 by Raymond Chen [1] and Mark Russinovich [2] respectively.

"They implemented only one compression algorithm.

It was memcpy."

[1] https://devblogs.microsoft.com/oldnewthing/20211111-00/?p=10...

[2] https://www.drdobbs.com/parallel/inside-softram-95/184409937

I remember using MemTurbo in the Windows 2000 era, though now I know it was mostly smoke and mirrors. My biggest gripe these days is too many "hardware accelerated" apps eating away VRAM, which is less of a problem with Windows (better over-commit) but which causes me a few crashes a month on KDE.

> Back in the MS-DOS days, when the RAM was sparse, there was a class of so-called "memory optimization" programs. They ultimately did nothing but claim they did the work. Must've sold pretty well nonetheless.

QEMM worked by remapping stuff into extended memory - in a time that most software wasn't interested in using it. It worked as advertised.

Quarterdeck made good stuff all around. Desq and DesqView/X were amazing multitaskers. Way snappier than Windows and ran on little to nothing.

From the FAQ:

> If some eligible files were found, the amount of disk space that can be reclaimed is shown next to the “Potential Savings” label. To proceed any further, you will have to make a purchase. Once the app’s full functionality is unlocked, a “Review Files” button will become available after a successful scan. This will open the Review Window.

I half remember this being discussed on ATP; the logic being that if you have the list of files, you will just go and de-dupe them yourself.

> the logic being that if you have the list of files, you will just go and de-dupe them yourself.

If you can do that, you can check for duplicates yourself anyway. It's not like there aren't already dozens of great apps that dedupe.

> there aren't already dozens of great apps that dedupe.

Most of those delete rather than use the features of APFS.

It didn't tell you how much disk space? It's supposed to. It only told you the number of files?

Only told me the number of files and it didn't even provide a list of files (their paths, etc.)

This seems like a bug. It is supposed to tell you the amount of disk space.

(Obviously it won't show the list until payment. That part is expected behavior.)

List is available after paying. Which makes a lot of sense.