Gregory's Server
@aardvark @jimluther i feel like i'm missing some lore here
|
4 comments
@chrisisgr8 @aardvark Oh yeah, Desktop Services is the non-UI part of the Finder code. Its functionality is also used by other parts of macOS - open/save UI, migration assistant, etc.  @jimluther @chrisisgr8 @aardvark If it weren’t for the fact that Spatial Finder is still (poorly) supported on modern macOS, would we even need .DS_Store files any more? @chrisisgr8 @jimluther that’s a picture celebrating John Sculley, captioned using words he once infamously spoke to a system software engineer right before entering what was going to be a long slog of a beta to get it out the door. |
@chrisisgr8 @aardvark The Macintosh Finder UI has always depended on storing info that tells it how to draw file and folder icons and how/where to draw Finder windows when they are reopened. There have been various places over the decades where that info is stored: FinderInfo in the file systems (now that is an extended attribute in file systems), desktop files, the Desktop Manager (and it's desktop database files), “Icon<cr>” files, the LaunchServices database, and .DS_Store files.
Every mechanism used tends to be visible on some filesystems (mostly non-Apple filesystems) because those filesystems don't provide anywhere to stuff that information other than a file.
Even making those files invisible is difficult when a filesystem is mounted on a non-Apple OS because different OSs have different mechanisms for making files hidden.
🤷♂️
@chrisisgr8 @aardvark The Macintosh Finder UI has always depended on storing info that tells it how to draw file and folder icons and how/where to draw Finder windows when they are reopened. There have been various places over the decades where that info is stored: FinderInfo in the file systems (now that is an extended attribute in file systems), desktop files, the Desktop Manager (and it's desktop database files), “Icon<cr>” files, the LaunchServices database, and .DS_Store files.