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

101–110 of 280 posts

Re: The Origins of DS_store (2006)

#101

Post by inferiorhuman »

worstspotgain wrote: post #41
kzrdude wrote: post #8

Earlier quoted context omitted.

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.

A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy. Once you pushed an app beyond the level of usage the developer had performed in their…

  Once you pushed an app beyond the level of usage the developer
  had performed in their initial tests, it would crawl to a near-halt
With HFS (unsure about HFS+) the first three extents are stored in the extent data record. After that extents get stored in a separate "overflow" file stored at the end of the filesystem. How much data goes in those three extents depends on a lot of things, but it does mean that it's actually pretty easy for things to get fragmented.

A bit more detail: the first three extents the resource and data forks are stored as part of the entry in the catalog (for a total of up to six extents). On HFS each extent can be 2^16 blocks long (I think HFS+ moved to 32-bit lengths). Anything beyond that (due to size or fragmentation) will have its info stored in an overflow catalog. The overflow catalogs are a.) normal files and b.) keyed by the id (CNID) of the parent directory. If memory serves this means that the catalog file itself can become fragmented but also the lookups themselves are a bit slow. There are little shortcuts (threads) that are keyed by the CNID of the file/directory itself, but as far as I can tell they're only commonly written for directories not files.

tl;dr For either of the forks (data or resource) once you got beyond the capacity of three extents or you start modifying things on a fragmented filesystem performance will go to shit.

Re: The Origins of DS_store (2006)

#103

Post by EvanAnderson »

neerajsi wrote: post #88
EvanAnderson wrote: post #55

Earlier quoted context omitted.

NTFS ACLs (aka file permissions) are stored in alternate data streams.

I work on ReFS and a little bit on NTFS. Alternate data streams are simply seekable bags of bytes, just like the traditional main data file stream. Security descriptors, extended attributes, reparse points and other file metadata are represented as a more general concept called an "attribute". You can't actually open a security descriptor attribute and modify select bytes of it to create an invalid security descripto…

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

Re: The Origins of DS_store (2006)

#104

Post by inferiorhuman »

netsharc wrote: post #45
dylan604 wrote: post #43

Earlier quoted context omitted.

It was all of the forked data that made dual format CDs/DVDs "interesting". In the beginning it was a trick. Eventually, the Mac burning software made it a breeze. Making a Mac bootable DVD was also interesting.

I recall seeing CD-ROMs that had both Mac and Windows software on it, and depending on which OS it was mounted on, it would show the Windows EXE or the Mac app... I wonder how that's done. I'm guessing there was a clever trick so files on both filesystems share the same data (e.g. if the program/game had a movie, it would only store the bytes of the movie once but its addressable as a file on each filesystem), but th…

As it starts about 32k in, the ISO 9660 superblock doesn't inherently conflict with an Apple partition map which starts at the beginning. Apple also had proprietary ISO 9660 extensions that add extra metadata to the directory entries much like the RockRidge extension does. Those would get ignored by non-Apple implementations of ISO 9660.

Microsoft went a different route with its long filename extensions (Joliet) – they simply created a whole different (UCS-2/UTF-16 encoded) directory tree. An ISO 9660 implementation that's compatible with Joliet will prefer the Unicode directory hierarchy and look there for files.

Re: The Origins of DS_store (2006)

#105

Post by kfarr »

Minor49er wrote: post #67
yellow_postit wrote: post #39

Finder remains one of those apps I still can’t make effective use of. Windows File Explorer for all its warts and changes still “just makes sense” to my brain vs how finder lays things out and expects you to browse. I’ve long since moved to command line or dual pane explorers but it’s something that makes me pause every time I do find myself in Finder for some reason.

I found myself in a similar situation. Learning some of the hotkeys in Finder for common tasks really helped me curb that feeling Command + O to open files/folders in Finder was a bit challenging to remember since Enter/Return just works in Explorer

Command + down arrow also works to open

Command + up arrow is a good shortcut to go up one level, surprisingly hard via gui

Re: The Origins of DS_store (2006)

#106

Post by prurigro »

heavyset_go wrote: post #91
prurigro wrote: post #85

Earlier quoted context omitted.

Google sent a copyright violation notice for each .DS_Store anyone at my company uploaded to Drive for nearly a year (yes, many support tickets were filed). It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.

That's scary considering how willingly they'll shutdown accounts for tripping their automated copyright violation service.

For sure! I made sure to have an open ticket with them until it was resolved so I'd have someone to call if some other automated system decided to shut down our services for it.

Re: The Origins of DS_store (2006)

#108

Post by prurigro »

janalsncm wrote: post #92
prurigro wrote: post #85

Earlier quoted context omitted.

Google sent a copyright violation notice for each .DS_Store anyone at my company uploaded to Drive for nearly a year (yes, many support tickets were filed). It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.

Why? Somehow DS_Store is claimed as a copyrighted file?

That's a good question. I get the impression the system is fairly opaque even to the people working there. I was told it was "resolved" and had my ticket closed a bunch of times, only to have another 30+ copyright violation emails the next time someone uploaded a batch of files from MacOS.

If the person who finally managed to figure it out ends to reading this, thanks for the resolution :)

Re: The Origins of DS_store (2006)

#110

Post by op00to »

al_borland wrote: post #29
metadat wrote: post #4

It'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...

macOS is tricky now. I just looked via Finder to see if I had any .DS_Store files on my network volumes, and it appeared not. However, when I went to Terminal, sure enough, they were there. I now can't trust Finder's ability to show hidden files, as it only shows the hidden files it thinks a user should care about, rather than all hidden files. Not good. Since my network shares are for a local Synology, it's not a a…

My synology NAS drops turds in lots of directories too.
Post reply on HN