I run a data recovery shop and got tired of hauling Mac drives to a Windows box just to make a file listing, so I built a native Mac version
Hey guys, I'd like to share what I've been working on.
I run a data recovery business, and one of the tools I lean on constantly is Snap2HTML. If you haven't used it, it takes a folder tree and saves the whole thing as a single HTML file you can browse and search offline. For us it's the easiest way to show a client exactly what we pulled off their drive, and it's a good record to keep on file for ourselves.
The catch is that it's Windows only. So any time a Mac drive came in, my process looked like this: do the recovery on the Mac, copy everything out to an external drive, carry that over to a Windows machine, run the snapshot there, then send the HTML back to the client. It works, but it's a lot of steps, and copying terabytes around just to generate a file listing gets old fast.
So I finally sat down and wrote a native Mac version in Swift.
The part I'm most happy with is the client side. Instead of emailing a multi megabyte HTML attachment that half the time gets stripped by a mail filter, I generate a link and text or email that. The client opens it in any browser, on a phone or a laptop, with nothing to install and no account to make. They can browse the folder tree and search it themselves, so they can confirm their photos or their QuickBooks file actually came back before they pay and before I ship the drive.
Each link has an expiry I pick when I create it (24 hours, 7 days, 30 days, or no expiry), and I can revoke it the moment a job closes, which also deletes the uploaded copy off the server. Worth saying clearly: only names, sizes and dates ever leave my machine. It never reads or uploads file contents. That matters a lot when you're handling somebody's personal drive.
A few Mac specific things I had to deal with that I didn't expect:
Photo libraries. iPhoto and Photos libraries are packages, so the Finder treats them as a single item. Collapsing a 200GB photo library into one row in a recovery report is useless, so those stay browsable while .app bundles still collapse into one entry. Turns out iPhoto libraries don't even have a file extension, they're only marked as packages by a Finder flag, which took a while to track down.
Full Disk Access. Photo libraries are blocked by macOS no matter what the file permissions say. Even ls fails on them. If you don't have Full Disk Access granted, they scan as completely empty and you'd never know. The app checks for this and warns you before scanning instead of silently handing a client an incomplete report.
Filenames. Asterisks are legal in Mac filenames but not Windows ones, and the original file format used asterisks as a separator, so those names came out corrupted. I rebuilt the data format as plain JSON, which sidesteps the whole problem.
On speed, I tested it against an old 36.7GB user folder with about 73,000 files in it. Takes roughly 6 seconds and spits out a 3.4MB HTML file. Search across the whole tree is instant since the list only renders what's on screen.
There's also a library of past snapshots with folders and tags, because I was starting to lose track of which HTML file went with which job.
It isn't released yet. I still need to notarize it and do more testing on real recovery drives. Mostly curious whether anyone else here has the same annoyance, and what you'd want out of something like this.
Big credit to RL Vision, who wrote the original Snap2HTML. Mine is a fresh implementation rather than a port, but the idea is entirely theirs and it's been a workhorse for me for years.