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

141–150 of 280 posts

Re: The Origins of DS_store (2006)

#141

Post by nottorp »

DEADMINCE wrote: post #72
dada78641 wrote: post #58

> Back in 1999 I was the technical lead for the Mac OS X Finder at Apple. At that time the Finder code base was some 8 years old and had reached the end of its useful life. Making any changes to it require huge engineering effort, and any changes usually broke two or three seemingly unrelated features. For Mac OS X we decided to rewrite the Finder from scratch. Not that I don't appreciate your work from back then, bu…

>The Finder has so many bizarre quirks and it's so slow to proliferate updates that it's just embarrassing Say what you will about Windows, but the Explore file manager has always been pretty rock solid.

Hmm. Wasn't it completely unreliable for moving around large numbers of files at the same time? Like if file #243 of 400 failed for some reason, you could actually lose data?

I don't know any more because I use Total Commander on Windows...

Re: The Origins of DS_store (2006)

#142

Post by OptionOfT »

robertoandred wrote: post #130
DEADMINCE wrote: post #72

Earlier quoted context omitted.

>The Finder has so many bizarre quirks and it's so slow to proliferate updates that it's just embarrassing Say what you will about Windows, but the Explore file manager has always been pretty rock solid.

Explorer can’t even sort folders by size…

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

Re: The Origins of DS_store (2006)

#144

Post by rf15 »

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.

Missing Stair effect - ignoring a problem does make everything progressively worse for everyone because the problems pile up.

Re: The Origins of DS_store (2006)

#145

Post by p_l »

kccqzy wrote: post #54
pseudalopex wrote: post #33

Earlier quoted context omitted.

The article said most browsers mark downloaded files.

That's done as part of xattr, or extended attributes. It's a very flexible system. For example you can add comments to a file so they are indexed by Spotlight.

Except NTFS does not have "extended attributes" in Linux/Irix/HPFS sense.

Every FILE object in the database is ultimately (outside of some low level metadata) a map of Type-(optional Name)-Length-Value entries, of which file contents and what people think of as "extended attributes" are just random DATA type entries (empty DATA name marks the default to own when you do file I/O).

It's similar to ZFS (in default config) and Solaris UFS where a file is also a directory

Re: The Origins of DS_store (2006)

#146

Post by rkachowski »

> Internally, those two components were known as Finder_FE and Finder_BE (Frontend and Backend).

Interesting to see that apps were split into front and back end (indeed, I'm surprised even that the terms existed) back in 1999.

Re: The Origins of DS_store (2006)

#147

Post by p_l »

EvanAnderson wrote: post #103
neerajsi wrote: post #88

Earlier quoted context omitted.

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

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

Re: The Origins of DS_store (2006)

#148

Post by Pikamander2 »

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?

The process likely went something like this:

1. Pirates uploaded a folder full of copyrighted files to Google Drive, accidentally including some DS_Store files along with the actual media.

2. The copyright owner filed a DMCA takedown on the whole folder, accidentally claiming ownership of a bunch of generic DS_Store files.

3. The above two steps have likely happened many times, not just once.

4. Google's takedown system now automatically flags DS_Store files as having multiple copyright violations.

5. A Google employee might be able to whitelist a user's individual DS_Store files to temporarily suppress the violation on their account, but since they can appear in different folders with different data and are constantly receiving new copyright claims, their system likely errs on the side of caution and continues to flag them as copyright violations so that Google doesn't accidentally lose its safe harbor protections.

In theory, a Google engineer could code in a special case to avoid this problem, but good luck finding and talking to one who's authorized to do so; Google is notorious for having one of the lowest employee;revenue ratios in the world and writing useless FAQs instead of having a proper support channel for when things go wrong.

Re: The Origins of DS_store (2006)

#149

Post by p_l »

Lammy wrote: post #123
rescbr wrote: post #86

Earlier quoted context omitted.

IIRC from that time, those CD-ROMs contained two tracks, one formatted with ISO 9660 and another with HFS+. Windows didn't come with HFS+ drivers so it ignored it, and probably MacOS prioritized mounting the HFS+ track.

I've seen some where the combined file size exposed on each track would be larger than a CD could hold, so there had to be something more going on. StarCraft and Brood War come to mind with the large StarDat.mpq / BrooDat.mpq files.

TL;DR ISO9660 provided an area to stuff type-tagged extension information for each directory entry.

In addition, first 32kB of iso9660 are unused, which allowed tricks like putting another filesystem metadata there.

By carefully arranging metadata on disk it was then possible to make essentially overlapping partitions, stuffing each filesystem metadata in area unused by the other, with files reusing the same space

Re: The Origins of DS_store (2006)

#150

Post by steve1977 »

OptionOfT wrote: post #140
steve1977 wrote: post #126

Earlier quoted context omitted.

Explorer uses a hidden desktop.ini file for this.

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.

I guess a more correct answer would have been that deskop.ini is used for some folder customizations.
Post reply on HN