The worst part is that .DS_Store assumes, even on remote (SMB) filesystems, that only one machine will ever be accessing the directory, and so stores things like view settings and icon positions and such. Which means that every mac computer that accesses that file share will be fighting with each other, overwriting their metadata, and sometimes triggering problems because one has half-overwritten the file while another is accessing it.
That metadata should have been stored locally on the mac (with info about what path it refers to), not on the remote system.
But it was pretty neat that you could arrange icons on a floppy disks and then give it to someone else and the icons were in the same position on their computer.
The filesystem already keeps track of moves/renames -- I can (and have) moved the files that the App Store downloads, and it still knows where they are.
These temporary files are terrible! I don't know which major Windows version started with the ".thumb" and "desktop.ini" files, but if I tell my OS to navigate and display me contents of a folder, please don't change anything in that folder! You should be assuming "read-only" as often as possible, and only assume anything else when explicitly stated to do so.
But instead, they create thumbnails. In the very same source folder. Shouldn't this stuff go on some cache in your windows directory?
Another thing is that 'System Volume Information' created on removable drives. And Android too creates its directory structure on every mounted drive..
The wikipedia links to a similar article on the windows thumbnail cache, where it claims from Vista onward that Windows has a central cache location for thumbnail caches.
When I set up new fileshares at work I used Filescreen templates to stop those being created on network shares (Example [1]).
Gnome creates it's own too, and I wish it would stop - the only solution seems to be to recompile libgio with the trash method redirected to delete[2].
Re:.DS_Store
by acomjean on Wednesday July 03, 2019 @08:07AM
(#20343535)
I thought those files were a compromise when apple went to OS_X and got rid of the old "resource fork" park of the mac OS finder system. This data was part of the file, and let the operating system know which program to open the file with (even if it didn't have a .ext). But it made it hard to interopt.. But I might be a little off.
Re:.DS_Store
by gumby on Wednesday July 03, 2019 @06:33AM
(#20343107)
I have been glad these are user-visible files rather than some obscure FS metadata (xattrs) that get lost or propagated unpredictably by various tools.
The way they did it means I can delete 'em or keep 'em depending on what I want to accomplish and that the'll work on any filesystem.
Re:.DS_Store
by burfog on Wednesday July 03, 2019 @02:00PM
(#20346813)
I got data loss when OLPC's Sugar desktop did this. I put the SD card into the machine to undelete something, and Sugar promptly overwrote my data by adding some useless nonsense desktop file.
For all these sorts of things, I really truly think "How dare they!" and much worse. It fills me with rage that an OS would do this.
https://github.com/github/gitignore/blob/master/Global/macOS...
The worst part is that .DS_Store assumes, even on remote (SMB) filesystems, that only one machine will ever be accessing the directory, and so stores things like view settings and icon positions and such. Which means that every mac computer that accesses that file share will be fighting with each other, overwriting their metadata, and sometimes triggering problems because one has half-overwritten the file while another is accessing it.
That metadata should have been stored locally on the mac (with info about what path it refers to), not on the remote system.
Overall, it's a very poorly designed feature.
[1]: https://www.samba.org/samba/docs/current/man-html/smb.conf.5...
But instead, they create thumbnails. In the very same source folder. Shouldn't this stuff go on some cache in your windows directory?
Gnome creates it's own too, and I wish it would stop - the only solution seems to be to recompile libgio with the trash method redirected to delete[2].
[1] https://dea.nbird.com.au/2014/11/19/windows-server-prevent-m...
[2] https://askubuntu.com/questions/229098/how-to-i-stop-ubuntu-...
https://en.wikipedia.org/wiki/Resource_fork
http://mirror.informatimago.com/next/developer.apple.com/doc...
The way they did it means I can delete 'em or keep 'em depending on what I want to accomplish and that the'll work on any filesystem.
For all these sorts of things, I really truly think "How dare they!" and much worse. It fills me with rage that an OS would do this.