Re:That Time I Recreated Photoshop in C++
by NobodyNada on Sunday March 16, 2025 @03:49PM
(#43381631)
Windows does the same thing with 'Thumbs.db' files. They're just hidden from you on Windows systems, just as .DS_Store files are hidden on Unix-like systems; but you'll see them if you use a thumb drive with both types of machines.
So why are the smb shares on my linux file servers full of millions .ds_store files but zero thumbs.db files? I have to run automated scripts to remove them regularly, and try to run the commands on the macs to stop them writing ds_store files to network shares [0]. But still it seems to magically reenable itself every now and then. This is a problem I have never had with windows machines and 'thumbs.db' files.
[0] https://web.archive.org/web/20190714230437/https://support.a...
Re:That Time I Recreated Photoshop in C++
by jamesfinlayson on Sunday March 16, 2025 @07:07PM
(#43383444)
I didn't think newer versions of Windows generated Thumbs.db either (well I think they do, but in some centralised location I thought rather than in every single individual directory).
Re:That Time I Recreated Photoshop in C++
by noisem4ker on Monday March 17, 2025 @08:40AM
(#43387892)
"Newer versions" ≥ Vista (2007)
They switched to storing thumbnails locally.
Re:That Time I Recreated Photoshop in C++
by NobodyNada on Monday March 17, 2025 @10:57AM
(#43389251)
Ah, guess my knowledge was a bit out of date then :) I haven't been a regular Windows user for quite some time. I thought I'd seen Thumbs.db files generated on flash drives by at least 7 though.
Re:That Time I Recreated Photoshop in C++
by jamesfinlayson on Monday March 17, 2025 @08:48PM
(#43394533)
Ah okay - I thought maybe it was Windows 7 (I never used Vista) and 7 doesn't feel like four versions ago.
If I recall, Windows does not generate thumbs.db files, thus file icons-as-pictures, on any non-local device.
Re:That Time I Recreated Photoshop in C++
by DidYaWipe on Monday March 17, 2025 @01:35AM
(#43385466)
Because Apple thinks nothing of spewing these turds all over every machine and directory you visit from a Mac, which is not just a dick move but also technically incompetent.
The next Mac visitor who comes along will overwrite the turd with his own, so that's a blunder.
Then there's the fact that they could have stored all the turds on the local machine, keyed by URI or path or network address. This would solve both the dickishness and the overwriting problem. And if a remote machine's path or address changed, whoop dee doo... you lost your Finder layout for that directory. Pretty low stakes.
Not to be too annoying, but that file is how it supports the feature on non-posix-compliant file systems (usually FAT). On filesystems that support file-streams (or the original HFS), that metadata is stored on the file itself
You're thinking of resource forks. .DS_Store is stored as ".DS_Store" even on APFS.
Considering how pushy Apple normally are when it comes to forcing their customers to use new things so they can obselete old ones, I am very surprised where Apple have drawn the line in supporting older systems.
Relevant: “The Mac, Metadata, and you” (2001) https://arstechnica.com/gadgets/2001/08/metadata/
First thing I used to install on macOS was Binaryage's superb asepsis utility, which intercepts the creation of .ds_store files and redirects them all to a local container folder, until SIP killed its development.
It always seemed suspicious to me that Apple, a company that is famously obsessed with UI/UX, would settle on such a ridiculous process for storing file metadata.
This is neat, shame they went completely the other way with file metadata. It forces a hidden .ds_store file in every single folder a mac touches just to store info like access time. Every other system stores this in the file itself.