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

271–280 of 280 posts

Re: The Origins of DS_store (2006)

#271

Post by mmaniac »

euroderf wrote: post #157
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…

> 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" ?

Prefixing the filename with ._ is Finder convention whenever you copy metadata to a filesystem which doesn't support resource forks, like FAT32

Re: The Origins of DS_store (2006)

#272

Post by tekknik »

beeboobaa3 wrote: post #266
tekknik wrote: post #262

Earlier quoted context omitted.

Well I was trying to tell you nicely, but you’ll figure it out before long. Banning someone because they commit a file you don’t like is definitely a sign of a controlling person.

Repeatedly. Besides, if you repeatedly pay such little care how can anything you do be trusted?

You’re right, people are born perfect so this is felony behavior. We should limit their rights as a result.

Thanks for giving me a new interview question.

Re: The Origins of DS_store (2006)

#273

Post by IIsi50MHz »

michaelcampbell wrote: post #251
klodolph wrote: post #116

Earlier quoted context omitted.

> One metadata and one the file contents. I’d say this is not the right way to describe a resource fork. Instead, think of it as two sets of file contents—one called "data" and one called "rsrc". On-disk, they are both just bytestreams. The catch is that you usually store a specific structure in the resource fork—smaller chunks of data indexed by 4-byte type codes and 2-byte integer IDs. Applications on the 68K norma…

>> One metadata and one the file contents. > I’d say this is not the right way to describe a resource fork. Instead, think of it as two sets of file contents—one called "data" and one called "rsrc". On-disk, they are both just bytestreams. I think it's a perfectly fine way. You're just coming at it from a wildly different level of abstraction. One could say yours is not the right way either and jump down into quantum…

GP is more accurate, because "file contents" could be in either or both. Not all files had a data fork, and not all files had a resource fork. Some metadata, such icon position, was also stored independently of the file, using the hidden Desktop database.

Re: The Origins of DS_store (2006)

#274

Post by IIsi50MHz »

reddalo wrote: post #176
OptionOfT wrote: post #140

Earlier quoted context omitted.

Negative. desktop.ini doesn't get edited when you switch (for example) from Details to List. Also, I think only the desktop allows moving icons around freely.

> only the desktop allows moving icons around freely I'm pretty sure Windows used to allow you to move icons around, I clearly remember making a mess on some Windows 98 folders. Maybe they removed that feature recently?

Windows stores/stored in the registry a limited number of file folders' icon layouts. Once you go over the limit, the oldest config is erased. I think the original limit was 200, but could be overridden using a registry key.

Re: The Origins of DS_store (2006)

#275

Post by robertoandred »

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.

You're saying the size of the folder's contents is its size? Wow, that would sure be useful information for a file explorer to expose.

Re: The Origins of DS_store (2006)

#276

Post by beeboobaa3 »

tekknik wrote: post #272
beeboobaa3 wrote: post #266

Earlier quoted context omitted.

Repeatedly. Besides, if you repeatedly pay such little care how can anything you do be trusted?

You’re right, people are born perfect so this is felony behavior. We should limit their rights as a result. Thanks for giving me a new interview question.

Stop being ridiculous. If you can't learn from your mistakes, even after it has been explained to you several times, you're the problem.

> limit their rights

Now you're just being weird. No one has an inherent "right" to contribute to a project.

Re: The Origins of DS_store (2006)

#277

Post by tekknik »

beeboobaa3 wrote: post #276
tekknik wrote: post #272

Earlier quoted context omitted.

You’re right, people are born perfect so this is felony behavior. We should limit their rights as a result. Thanks for giving me a new interview question.

Stop being ridiculous. If you can't learn from your mistakes, even after it has been explained to you several times, you're the problem. > limit their rights Now you're just being weird. No one has an inherent "right" to contribute to a project.

Yea you missed the point. The point being you’re overreacting to a nonissue. But regardless it’s easy enough to filter your types out of my own projects and teams so I don’t care anymore.

Re: The Origins of DS_store (2006)

#278

Post by beeboobaa3 »

tekknik wrote: post #277
beeboobaa3 wrote: post #276

Earlier quoted context omitted.

Stop being ridiculous. If you can't learn from your mistakes, even after it has been explained to you several times, you're the problem. > limit their rights Now you're just being weird. No one has an inherent "right" to contribute to a project.

Yea you missed the point. The point being you’re overreacting to a nonissue. But regardless it’s easy enough to filter your types out of my own projects and teams so I don’t care anymore.

lol, ok bro. glad to not have to work with you as well since you're really channeling that "can't learn from my mistakes and will keep burdering others with them! Wait, why don't you like me?" energy

Re: The Origins of DS_store (2006)

#279

Post by krackers »

jwells89 wrote: post #97
wsc981 wrote: post #60

Earlier quoted context omitted.

I never quite understand why the Finder gets so much hate. Personally I think it’s quite ok. I especially like columns navigation, quite effective for me to get around. It does make me wonder though, how do you feel about System 7.0 Finder?

I have similar feelings about the Finder and also don't quite get the love for Windows Explorer. It's just ok and if it were practical to replace it with just about any common Linux file manager on my Windows boxes I'd do so without a second thought. NeXT/Mac column view are great and should be table stakes in a file manager in my opinion.

Finder used to be a lot worse, with tabs and once you've got all the shortcuts down it's not too bad. Spring loaded folders are really handy. Some time around 10.10 they added a shortcut for showing invisible files, which is absolutely essential for any developer. If I had to pick one area to improve, besides the ds_store littering it'd be general network file system support, SMB has always been a second class citizen and even AFP is just slow.

Re: The Origins of DS_store (2006)

#280

Post by spopejoy »

sherburt3 wrote: post #66

I am MacOS's biggest fanboy and Tim Cook's strongest soldier but I will also say the Finder is one of the dumbest file explorers I've ever experienced in my life

I like many things about Mac OS but I do wonder about the quality of the low-level software engineering.

The preponderance of bespoke NIH is glaring: filesystems, network protocols, "resource forks" (this one goes WAY back to pascal-OS days). Given that OS X was a significant rewrite and embrace of Posix, it's a mystery why they wouldn't have gone further with this.

I think the lack of a mature server OS reflects this. Single-user allows for a lot of workarounds, but a true multiuser runtime can't be hipster for its own sake.

Post reply on HN