It’s a good thing I never created OS file systems because I would have balls.chin files everywhere. Well, the truth is that someone would have forked it just to change that, then I would have raged and abandoned the project, then a competent maintainer would have grabbed it. What a world.
thumbs.dbsays helloThe most reliable fingerprint.
Fuckin
thumbs.dbandlost+foundhiding on every USB stick.Seriously fuck thumbs.db anywhere it can be found.
THIS IS WHY NTFS HAS ALTERNATE DATA STREAMS, USE THEM YOU FUCKERS YOU CREATED IT.
Or as my parents call them, “A virus!”
What drives me batty about
thumbs.dbis that on a modern high end machine with an nvme drive it’s not meaningfully faster then just regenerating thumbnails on demand every time, and in fact can be slower under some circumstances. Yet there’s no “I don’t need this turn it off” option.also now that we have jpegxl you can just load the first bit of data for a thumbnail, lmao
What about remote drves though?
For whatever insane windows-y reason, having a
thumbs.dbfile on a network share is one of those slower scenarios for me. Which is odd because you’d expect that to be the kind of situation where it’s actually useful.
I have lost+found on my Linux drives… what am I doing wrong?
Nothing.
If you run fsck (filesystem check), it will look for blocks of data that look like files, but have no actual filename attached. Simplified, that can happen as a result of unexpected shutdowns (like kernel panic) or IO conflicts (where one process deletes the file but the other writes data to where the file used to be). If fsck finds such “lost files”, it will put them in lost+found on the respective volume.
If you have trouble with missing files after a crash, it might be worth looking for them there. Otherwise, it probably doesn’t matter.
Wait until they cross paths with the
._DS_Storeabomination.
