The Origins of DS_store (2006)

Original Article ↗ Hacker News Discussion ↗

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.