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

191–200 of 280 posts

Re: The Origins of DS_store (2006)

#191

Post by EvanAnderson »

p_l wrote: post #147
EvanAnderson wrote: post #103

Earlier quoted context omitted.

Help me understand the terminology. I thought alternative data streams were just non-resident attributes. Attributes like "$SECURITY_DESCRIPTOR" have reserved names but, conceptually, I thought were stored in the same manner as an alternative data stream. (Admittedly, I've never seen the real NTFS source code-- I've only perused open source tools and re-implementations.)

Essentially, attribute names directly specify the attribute type - so $SECURITY_DESCRIPTOR declared the entry in FILE attribute list to be a security descriptor. DATA attributes have another name field to handle multiple instances

I see. So there's one more layer of indirection there that I'm missing.

Re: The Origins of DS_store (2006)

#192

Post by dreamcompiler »

thought_alarm wrote: post #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 Cl…

> I have a global hot key to bring up the Applications folder

Not global, but as long as you're in the Finder cmd-shift-A opens the Applications folder. cmd-shift-U opens the Utilities folder.

Re: The Origins of DS_store (2006)

#193

Post by sznio »

OptionOfT wrote: post #142
robertoandred wrote: post #130

Earlier quoted context omitted.

Explorer can’t even sort folders by size…

That's because folders have no size. It requires calculating children size recursively.

It could be done quickly by reading the MFT. WizTree can calculate the size of all 236k directories/800k files on my system in two seconds. For some reason, Explorer takes ~10 seconds to calculate the size of a single directory (Program Files, 17k directories, 240k files). If Explorer just did what WizTree does, it could actually show and sort by directory sizes.

Re: The Origins of DS_store (2006)

#194

Post by account42 »

smix96 wrote: post #170
klodolph wrote: post #117

Earlier quoted context omitted.

Enough to teach people to use a global git core.excludesfile, IMO. Same place you should put rules for Emacs / Vim swap files.

Totally correct. Files which are unrelated to the project don't belong in .gitignore.

It makes sense to add an ignore for .* though and then specifically unignore only those dotfiles/directories that you actully want checked in.

Re: The Origins of DS_store (2006)

#195

Post by al_borland »

smix96 wrote: post #170
klodolph wrote: post #117

Earlier quoted context omitted.

Enough to teach people to use a global git core.excludesfile, IMO. Same place you should put rules for Emacs / Vim swap files.

Totally correct. Files which are unrelated to the project don't belong in .gitignore.

This may be technically correct, and I do have .DS_Store in my global, but I also put it in projects, because I know not everyone on my team is going to do that. I add it to the .gitignore in projects to save me from other people junking up the project. It’s a lot easier to add some lines to a file than it is to micromanage the global file for every potential future contributor.

Re: The Origins of DS_store (2006)

#196

Post by Waterluvian »

al_borland wrote: post #195
smix96 wrote: post #170

Earlier quoted context omitted.

Totally correct. Files which are unrelated to the project don't belong in .gitignore.

This may be technically correct, and I do have .DS_Store in my global, but I also put it in projects, because I know not everyone on my team is going to do that. I add it to the .gitignore in projects to save me from other people junking up the project. It’s a lot easier to add some lines to a file than it is to micromanage the global file for every potential future contributor.

This touches on something I've learned to be more mindful of: the "right answer" (especially to a techie) is often not the right answer in real world cases.

Re: The Origins of DS_store (2006)

#197

Post by euroderf »

ggm wrote: post #181
euroderf wrote: post #157

Earlier quoted context omitted.

> 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. Prefixing the file name with a single dot - is this a file system convention ? Or just a "good idea" ?

Unix convention to hide. .Files hidden from ls unless -a used but cd .config/ works fine. It matched the use of . For "this dir" and .. for "parent dir" also hidden by default. It was in v7 on a pdp11, my first experience of Unix in 1980. Probably pre-dated that.

Oh sure. I started with v6 on a pdp-10 in 1979. And the leading dot is ingrained in my brain.

But what I'm wondering about is the idea of associating (for example) "myfile.xyz" and ".myfile.xyz". I've never heard of this as a convention for associating metadata.

Re: The Origins of DS_store (2006)

#198

Post by nanna »

thiht wrote: post #190
nanna wrote: post #185

Thankfully Emacs's file manager Dired lets me easily pretend this pesky little file, as well as those produced by a LaTeX run, doesn't exist. (setq dired-omit-mode t dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")

"easily" you say?

Well sure it's a bit noisy but it's just a bit of regex.

Re: The Origins of DS_store (2006)

#200

Post by DidYaWipe »

lyu07282 wrote: post #183
DidYaWipe wrote: post #12

Not to mention that it's an obnoxious and incompetent design. Look at the fact that Mac OS litters every other computer it visits with turds, for its own (and in fact only one user's) benefit. It's doubly stupid because the next browsing Mac that comes along trounces the previous one's turd. If Apple wanted to store view settings for remote volumes (or even local volumes), the competent design would have been to stor…

The funny part is actually that its not supposed to create DS_store everywhere: > There is also an unfortunate bug that is not fixed to this day that result in an excessive creation of .DS_Store file. 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 guar…

By that logic, though, there was never any reason to implement it in the first place.
Post reply on HN