The Origins of DS_store (2006)
arno.org
The Origins of DS_store (2006)
1–10 of 280 posts
Re: The Origins of DS_store (2006)
#2Aside from this file, the "fork" concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or zip distinctly. Implementing Mac compatible file support in Unix meant treating the resource fork first class and the obvious way you do it is for each file have .file beside it.
You couldn't map all the properties of the resource fork into an inode block of the time in UFS. It has stuff like the icon. More modern fs may have larger directory block structure and can handle the data better.
Re: The Origins of DS_store (2006)
#3Aside from this file, the "fork" concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
You have the same "resource fork" concept in Unix xattrs and NTFS streams.
Re: The Origins of DS_store (2006)
#4It's worth mentioning how to turn off the creation of .DS_Store files by default while browsing network volumes - otherwise the directory modified timestamps are updated as you browse using the Finder, which is Just Plain Terrible.
https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...
Re: The Origins of DS_store (2006)
#5Aside from this file, the "fork" concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
You have the same "resource fork" concept in Unix xattrs and NTFS streams.
No disagree, Both came later IIRC. Melbourne unis work on appletalk and Apple file system support was in the late 80s and I believe POSIX xattr spec work was mid nineties, NTFS was '93 or so. The fork model in apple file store was eighties work.
Re: The Origins of DS_store (2006)
#6Maybe unrelated to this, but I noticed fairly recently that my backups from my macbook now backup seemingly randomly modified pdf and txt files all over the disk. My guess is that whenever I search for something, it decides to touch a couple of hundred files (but not ALL pdf/txt files for some reason).
Re: The Origins of DS_store (2006)
#7Aside from this file, the "fork" concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
NTFS has alternate data streams. I think its hardly ever used.
https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
Re: The Origins of DS_store (2006)
#8Aside from this file, the "fork" concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
Resource fork used to contain all the stuff you could edit with ResEdit (good old times!) right? Icons, various gui resources, could be text and translation assets too. For example Escape Velocity plugins used custom resource types and a ResEdit plugin made them easy to edit there.
Re: The Origins of DS_store (2006)
#9> Those files should only be created if the user actually makes adjustments to the view settings or set a manual location for icons in a folder. That’s unfortunately not what happens and visiting a folder pretty much guarantees that a .DS_Store file will get created
This is my number one frustration with the Finder.
You can customize the look and size of individual folder windows in many interesting ways, al a the Classic Mac OS Finder, which is a really great feature. But if you blow through that same folder in a browser window then most of those customization are lost, overwritten with the settings of that browser window, even if you never change anything.
What's the point of allowing all of these great customizations when they're so easily clobbered?
I have a global hot key to bring up the Applications folder. I'd love to customize the look of that window, but it's pointless. Whenever I hit that hot key I have no idea what I'm going to get. It's always getting reset.
By the way, the reason it does this is because the Finder has no way to set a default browser window configuration. So instead, it just leaves behind the current browser settings in each folder it visits. Super frustrating.
Re: The Origins of DS_store (2006)
#10It's worth mentioning how to turn off the creation of .DS_Store files by default while browsing network volumes - otherwise the directory modified timestamps are updated as you browse using the Finder, which is Just Plain Terrible. https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...
Personally I make sure mac users do this before they get write access to a network share. It's just a matter of common curtesy IMHO.