Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Origins of DS_store (2006)

arno.org

Post reply on HN
Print view View original

201–210 of 280 posts

Re: The Origins of DS_store (2006)

#201

Post by grishka »

js2 wrote: post #73
slmjkdbtl wrote: post #50

I remember there used to ways to turn off the creation of .DS_Store but they removed it, I can't figure out for life why they would make such a change. I had to write a program [0] to watch the entire file system and delete .DS_Store as soon as they're created. [0] https://github.com/slmjkdbtl/dskill

You can turn it off for network volumes: defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE https://support.apple.com/en-us/102064 I don't recall there ever being a way to turn it off for local volumes.

Is it also possible to do this for removable media?

It seems to be the first time I'm seeing Apple themselves officially recommending a "defaults write" command.

Re: The Origins of DS_store (2006)

#202

Post by demondemidi »

gumby wrote: post #69
slmjkdbtl wrote: post #50

I remember there used to ways to turn off the creation of .DS_Store but they removed it, I can't figure out for life why they would make such a change. I had to write a program [0] to watch the entire file system and delete .DS_Store as soon as they're created. [0] https://github.com/slmjkdbtl/dskill

Why? I just ignore them.

That’s the easy solution. But some people are absolute control freaks and would rather go nuts about a hidden file than actually spend their energy creating things. Very telling.

Re: The Origins of DS_store (2006)

#203

Post by marcosdumay »

plasticeagle wrote: post #129
userbinator wrote: post #113

Earlier quoted context omitted.

I remember playing around with setting up a Hackintosh, and found all those errors in the system logs --- then realised that an actual working Mac generates much the same (ignorable) errors.

To be fair to Apple here, so does every other operating system. Linux system logs are filled with errors too. In general, keeping the logs of even a moderately complex application "clean" - so that the only errors logged are real errors, in some poorly defined meaning of "real" - is very hard. For operating systems it must be straight up impossible.

> Linux system logs are filled with errors too.

Mostly only due to misbehaving hardware. Something that should really not happen on a Mac. And "filled" is way hyperbolic, there usually isn't a lot of it.

Re: The Origins of DS_store (2006)

#204

Post by nox101 »

kzrdude wrote: post #8
ggm wrote: post #2

Aside 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.

I always thought the resource fork as a good idea poorly implemented. IMO they should have just given you a library that manipulated a regular file. Then you could choose to use it or not but it would still be a single file. It could have a standard header to identify it and the system could look inside if that header was there.

One of the big problems with resource forks was that no other system supported them so to host a mac file on a non-mac drive or an ftp server, etc, the file had to be converted to something that contained both parts, then converted back when brought to the mac. It was a PITA.

Re: The Origins of DS_store (2006)

#205

Post by marcosdumay »

Andrex wrote: post #188
seabird wrote: post #82

Earlier quoted context omitted.

Up until 7, and even afterward in some areas, Windows got things right from an interface standpoint. People seem to forgot that Microsoft dumped large amounts of time and money into figuring out how people use computers and developed their desktop environment accordingly. I've used Windows, macOS, and more Linux DEs than I care to admit. The only thing that tops the Windows DE is KDE, which isn't a massive departure…

Dynamically-loaded context options (with any user-perceptible lag whatsoever) has to be one the greatest UX sins I can think of. Like apps stealing focus on startup (looking at you, Adobe!)

> with any user-perceptible lag whatsoever

About that part... Modern computers are insanely fast. How does every single piece of software manages to fill half a minute of CPU or disk I/O for enumerating some 3 or 4 items?

It's absurd.

I use Firefox inside eatmydata nowadays, because it spends 10 minutes enumerating the same 2 directories every time it starts up (hundreds of thousands of times). The start menu and equivalents everywhere are already famous. Windows can't search files nowadays, not only it doesn't work, but it never ends either... The list is endless.

Re: The Origins of DS_store (2006)

#206

Post by mort96 »

phyzix5761 wrote: post #133
slmjkdbtl wrote: post #50

I remember there used to ways to turn off the creation of .DS_Store but they removed it, I can't figure out for life why they would make such a change. I had to write a program [0] to watch the entire file system and delete .DS_Store as soon as they're created. [0] https://github.com/slmjkdbtl/dskill

find / -name ".DS_Store" -exec rm {} \; 2>/dev/null Put that in a script and add it to your crontab.

That's gonna be incredibly slow on most developer machines. node_modules, __pycache__, Cargo target/ folders, Yocto build folders, .git folders, etc etc etc -- all my machines which are ever used for development end up with such a gargantuan amount of small files across the filesystem that any operation which involves iterating through all of them takes forever.

Besides, there are .DS_Store I really don't wanna delete. Notably, there are git repos which have erroneously committed .DS_Store files; I don't wanna make those repos dirty by deleting them.

Re: The Origins of DS_store (2006)

#207

Post by [deleted] »

silverwind wrote: post #168
js2 wrote: post #73

Earlier quoted context omitted.

You can turn it off for network volumes: defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE https://support.apple.com/en-us/102064 I don't recall there ever being a way to turn it off for local volumes.

There was https://github.com/binaryage/asepsis but Apple broke it IIRC.

[deleted]

Re: The Origins of DS_store (2006)

#208

Post by js2 »

silverwind wrote: post #168
js2 wrote: post #73

Earlier quoted context omitted.

You can turn it off for network volumes: defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE https://support.apple.com/en-us/102064 I don't recall there ever being a way to turn it off for local volumes.

There was https://github.com/binaryage/asepsis but Apple broke it IIRC.

It was a hack, not anything Apple ever supported:

> At core Asepsis provides a dynamic library DesktopServicesPrivWrapper which gets loaded into every process linking against DesktopServicesPriv.framework. It interposes some libc calls used by DesktopServicesPriv to access .DS_Store files. Interposed functions detect paths talking about .DS_Store files and redirect them into a special prefix folder. This seems to be transparent to DesktopServicesPriv.

> Additionally Asepsis implements a system-wide daemon asepsisd whose purpose is to monitor system-wide folder renames (or deletes) and mirror those operations in the prefix folder. This is probably the best we can do. This way you don’t lose your settings after renaming folders because rename is also executed on folder structure in the prefix directory.

Unsurprisingly, you can no longer do anything like this with SIP. If you're willing to disable SIP, there are forks of the project that apparently still work.

Re: The Origins of DS_store (2006)

#209

Post by js2 »

grishka wrote: post #201
js2 wrote: post #73

Earlier quoted context omitted.

You can turn it off for network volumes: defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE https://support.apple.com/en-us/102064 I don't recall there ever being a way to turn it off for local volumes.

Is it also possible to do this for removable media? It seems to be the first time I'm seeing Apple themselves officially recommending a "defaults write" command.

Not sure if this still works, but:

  defaults write com.apple.desktopservices DSDontWriteUSBStores -bool TRUE
Re: defaults:

https://support.apple.com/guide/terminal/edit-property-lists...

Re: The Origins of DS_store (2006)

#210

Post by adrian_b »

ggm wrote: post #5
senderista wrote: post #3

Earlier quoted context omitted.

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.

The concept of extended file attributes has been introduced by HPFS, in OS/2, in 1989.

From HPFS it was taken by SGI XFS (the ancestor of Linux XFS) and MS NTFS, both in 1993.

From there it has spread to various other file systems and specifications.

The concept of resource forks is earlier, but both are examples of using alternate data streams in a file.

Post reply on HN