As far as I know, not in a way that’s portable across file systems. My understanding is these files persist information about the view of the directory. Things like icon positions, whether it is viewed as a list or as icons etc. All options are a tradeoff in some way.
You could persist it in a DB on the machine itself, but then every machine would have a different view and you might lose that between machines or on upgrades. The classic app icon + arrow image + applications folder alias with some basic text instructions in the window for installing an app via drag and drop (and for that matter sizing the window to have all of that nicely framed in view) is all in this data. A per-machine setting would mean app developers couldn’t store that data with the install image, or it would require disks themselves to be carriers of that data / special file systems for software install disk images.
Per file metadata a la the classic Mac resource fork is an option, but osx moved away from that precisely because only HFS supported it and other OSes and systems would silently drop the fork. Not a problem in a pre-interconnected computing world, but a huge problem in a world where your file might pass through multiple file systems on its way to you. That’s one of the reasons why classic Mac software archives still hold everything in .sit files, since that keeps the resource fork intact for the contents while being storable on non-HFS file systems.
And the choice they have gone with (per directory hidden files) has the downside of littering systems with misc files that other users don’t care about
You could persist it in a DB on the machine itself, but then every machine would have a different view and you might lose that between machines or on upgrades. The classic app icon + arrow image + applications folder alias with some basic text instructions in the window for installing an app via drag and drop (and for that matter sizing the window to have all of that nicely framed in view) is all in this data. A per-machine setting would mean app developers couldn’t store that data with the install image, or it would require disks themselves to be carriers of that data / special file systems for software install disk images.
Per file metadata a la the classic Mac resource fork is an option, but osx moved away from that precisely because only HFS supported it and other OSes and systems would silently drop the fork. Not a problem in a pre-interconnected computing world, but a huge problem in a world where your file might pass through multiple file systems on its way to you. That’s one of the reasons why classic Mac software archives still hold everything in .sit files, since that keeps the resource fork intact for the contents while being storable on non-HFS file systems.
And the choice they have gone with (per directory hidden files) has the downside of littering systems with misc files that other users don’t care about