The Origins of DS_store (2006)

Original Article ↗ Hacker News Discussion ↗

macOS’s .DS_Store files and legacy concepts like resource forks spark strong reactions because they mix clever metadata design with messy real‑world behavior. Commenters trace how alternate data streams, extended attributes, and dual-fork files evolved across Mac, Windows, and older systems, and why Apple ended up littering network shares and removable media with hidden files that confuse non-Mac users and version control systems. Many argue Apple should have centralized this metadata or limited it to local use, and share workarounds such as Samba veto rules, system defaults, and cleanup tools while also critiquing Finder’s design and technical debt.

Mac resource forks & historical context

  • Classic Mac files had two “forks”: data and resource, both byte streams.
  • Resource forks stored code, UI assets, icons, menus, strings, and app metadata; many classic apps kept almost everything there.
  • Early filesystems (MFS/HFS) and limited folder support pushed Apple toward this design; resources were accessed via a Resource Manager API.
  • HFS/HFS+ implementation (extents, overflow catalogs) made large or fragmented forks slow and fragile; many were happy when resource forks were de‑emphasized in Mac OS X.
  • APFS still supports resource forks (e.g., custom icons), accessible via a special path; modern code can treat them as normal random-access streams.

Extended attributes, alternate streams & EAs

  • Unix xattrs, NTFS alternate data streams (ADS), HPFS/OS/2 Extended Attributes, and Mac resource forks are seen as variations on “multiple named data streams per file.”
  • NTFS stores many things as attributes: unnamed $DATA for main content, named $DATA for ADS, $EA/$EA_INFORMATION for EAs, $SECURITY_DESCRIPTOR for ACLs, etc.
  • Windows subsystems (POSIX, Interix, WSL) and tools use EAs/ADS for POSIX metadata, capabilities, and xattrs analogues.
  • Some note malware and obscure tooling as primary ADS users; others cite real-world use (e.g., Dropbox metadata, “downloaded from internet” flags).

.DS_Store behavior, bugs & mitigation

  • .DS_Store stores Finder view state and icon positions per folder.
  • Intended design (per article): only write when a user customizes a folder. Reported behavior: merely visiting a folder almost always creates the file, seen as a long‑standing bug.
  • This causes “file litter” on local drives, removable media, network shares, archives, and git repos; many see it as un-Apple-like polish.
  • Workarounds mentioned:
    • System defaults to prevent writing on network/USB volumes.
    • Samba/WebDAV “veto”/ignore rules.
    • Synology options and its own metadata dirs.
    • Tools using FSEvents to delete .DS_Store on creation, or find/dot_clean cleanup scripts.
  • Some argue Finder should store per-user view settings centrally; others note difficulties with stable identifiers and concurrent updates but still consider the current per-folder approach a poor tradeoff.

Cross‑platform metadata files (.DS_Store, ._*, others)

  • When copying Mac files to non‑Apple filesystems without forks/xattrs (e.g., FAT), macOS synthesizes ._* AppleDouble files to hold forks/metadata; seen as another kind of “turds.”
  • Network appliances (e.g., NAS) also introduce their own metadata dirs (@eaDir), compounding clutter.
  • Windows has its own analogues (desktop.ini, Thumbs.db, ADS zone info), though modern Windows is said to be more conservative on network shares.

Finder, Explorer & UX opinions

  • Many find Finder confusing or limited compared to Windows Explorer; others like column view, spring‑loaded folders, and keyboard shortcuts.
  • Complaints include: fragile per-folder settings, network hangs, odd keybindings (Enter = rename), and long‑standing quirks.
  • Some recall multiple Finder rewrites and fear another might devolve into an iPad‑style, less capable file browser.
  • Others argue all major OSes litter metadata somehow (Linux dotfiles, Windows system files), and that this is an inevitable side effect of richer UX and metadata.