I suspect that some paid places use automated license plate readers to check for non-payment, or could be checking manually but having all the cars front-in could still save the manual checker the labor of walking around cars.
edit: In recent years I've actually been in parking garages and seen seen a hapless security guard walking car to car, photographing the back of each one. (I've also seen 'meter-readers' doing the same thing in paid street parking areas.) I wouldn't be surprised if a car-mounted version also existed, which is what I meant when I speculated about automation.
I think I saw that F3 is cross-platform. I used something else last time I needed it (it was a microSD), but I'm struggling to remember what it was. I'll update you if I remember. Nope, it was F3!
This and make sure to use the right test method. Sketchy SSDs will pretend to accept all the data you put in 'em, and then just silently throw away data that's over their capacity. Use a method that writes and then verifies.
I ain't about to play headgames on what I have and haven't salvaged already, I must keep track of what device stores what, what filename is what, and what dates are what.
This is precisely the headache I'm trying to save to you from: micromanaging what you store for the purpose of saving storage space. Store it all, store every version of every file on the same filesystem, or throw it into the same backup system (one that supports block-level deduplication), and you won't be wasting any space and you get to keep your organized file structure.
Ultimately, what we're talking about is storing files, right? And your goal is to now keep files from these old systems in some kind of unified modern system, right? Okay, then. All disks store files as blocks, and with block-level dedup, a common block of data that appears in multiple files only gets stored once, and if you have more than one copy of the file, the difference between the versions (if there is any) gets stored as a diff. The stuff you said about filenames, modified dates and what ancient filesystem it was originally stored on... sorry, none of that is relevant.
When you browse your new, consolidated collection, you'll see all the original folders and files. If two copies of a file happen to contain all the same data, the incremental storage needed to store the second copy is ~0. If you have two copies of the same file, but one was stored by your friend and 10% of it got corrupted before the sent it back to you, storing that second copy only costs you ~10% in extra storage. If you have historical versions of a file that was modified in 1986, 1992 and 2005 that lived on a different OS each time, what it costs to store each copy is just the difference.
I must reiterate that block-level deduplication doesn't care what files the common data resides in, if it's on the same filesystem it gets deduplcated. This means you can store all the files you have, keep them all in their original contexts (folder structure), without wasting space storing any common parts of any files more than once.
Either I'm massively misunderstanding why it is you want to curate your backup by hand, or you're missing the point of block-level deduplication. Shrug, either is possible.
across the different devices and media, the folder and file structure isn't exactly consistent.
That's the thing: it doesn't need to be. If your backup software or filesystem supports block-level deduplication, all matching data only gets stored once, and filenames don't matter. The files don't even have to 100% match. You'll still see all your files when browsing, but the system is transparently making sure to only store stuff once.
Some examples of popular backup software that does this are Borgbackup and Restic, while filesystems that can do this include BTRFS and ZFS.
"My $5 wrench says you better start installing Windows."