.DS_Store は、1999年に Mac OS X 向け Finder を作り直した際に生まれた Desktop Services Store の略称- 当時の Finder コードベースは約8年物で、小さな変更にも大きなコストがかかり、無関係に見える機能が壊れることもあったため、全面的な再実装が必要だった
- 新しい Finder はユーザーインターフェースとバックエンドを分離し、バックエンドはファイル列挙、変更監視、アイコン位置やフォルダ設定といった メタデータ を担当した
- Finder のバックエンドは Finder の外でも使える公開 API の候補となり、Finder を「Desktop」に改名する案とも重なって Desktop Services という名前が付いた
.DS_Store は本来、表示設定やアイコン位置を変更したときにだけ作られるべきだったが、バグのためフォルダを訪れただけでも生成されることが多い
Desktop Services Store という名前の誕生
- 1999年に Apple で Mac OS X Finder を新しく作っていた時点で、既存の Finder コードベースは約 8年 が経過していた
- 変更には大きなエンジニアリング労力が必要だった
- 変更を行うと、たいてい無関係に見える機能が2〜3個壊れた
- Mac OS X 向け Finder は最初から書き直すことが決定された
- 再実装の過程で、Finder の ユーザーインターフェース と 中核機能バックエンド を分離した
- 内部名はそれぞれ
Finder_FE と Finder_BE だった
- バックエンドはファイル列挙、ファイルシステム変更監視、メタデータ処理、アイコン位置、フォルダ設定を担当した
- Finder のバックエンドは Finder の外部でも有用になり得るため、いずれ 公開 API として提供する計画が生まれた
- 以前に
Icon Services と Navigation Services という名前を決めた経験を踏まえ、Desktop Services という名前が選ばれた
- 当時は Finder を「Desktop」に改名する案も検討されていた
.DS_Store は "Desktop Services Store" に由来する名前- 先頭の
. は Unix 系 OS や Mac OS で不可視ファイルとして扱わせるための選択だった
生成条件とその後の影響
- 名前はもっと説明的なものにもできたが、すでに広く使われるようになった後では変更が難しい状態だった
.DS_Store ファイルは本来、ユーザーがフォルダの表示設定を調整したり、アイコン位置を手動で指定したりしたときにだけ作られるべきものだった
- しかし未修正のバグのため、ファイルが過剰に生成される
- 実際には、フォルダを訪れるだけでも
.DS_Store ファイルが生成される状況がほぼ確実に起きる
Finder_BE、すなわち Desktop Services は Finder の外部でも使われた
Navigation Services、つまり開く／保存ダイアログもその後これを使うようになった- Mac OS の初期リリースでは
Navigation Services はこれを使っていなかった
Desktop Services API はまだ完全には公開されていない
1件のコメント
Hacker News のコメント
このファイル以外にも、Mac ファイルシステムの フォーク（fork） という概念で戸惑う瞬間があった
ここでいう fork は
fork()ではなく、ファイルシステム内でデータ構成要素とリソース構成要素が対になって存在する構造で、一方はメタデータ、もう一方はファイル内容のように扱われていたUnix ではメタデータはディレクトリブロックや inode 側にあり、ファイルに固有に結び付いた形式ではなかったため、
tar、cpio、zipのような構造が別途表現する必要があったUnix で Mac 互換ファイル対応を実装するには resource fork を第一級データとして扱う必要があり、自然な方法は各ファイルの横に
.fileのようなファイルを置くことだった当時の UFS の inode ブロックにはリソースフォークのすべての属性をマッピングできず、アイコンのようなものも入っていた。より現代的なファイルシステムではディレクトリブロック構造がより大きく、こうしたデータをよりうまく扱える
むしろファイル内容が 2 セットあると見るのが正しく、一方は
data、もう一方はrsrcと呼ばれ、ディスク上ではどちらも単なるバイトストリームだったただし resource fork には通常、4 バイトのタイプコードと 2 バイト整数の ID でインデックスされる小さなデータ片の構造を保存していた
68K Mac アプリケーションはコード、メニュー、ダイアログ、画像、アイコン、文字列など、ほぼすべてを resource fork に入れており、昔の Mac アプリを変換せずに PC や Unix にコピーすると空のファイルのように見えた
そのため Mac アプリをネットワークで送るには単一ストリームにエンコードする必要があり、初期には BinHex
.hqxや MacBinary.bin、後には Stuffit.sitアーカイブが使われたこの構造が inode に合わない理由は、実質的にファイルを丸ごと 1 つ押し込もうとするのと同じだからだ。resource fork 構造自体には 16MB の制限があったが、別のデータストリームとして扱えば望むだけ大きくすることもできた
例えば Escape Velocity のプラグインはカスタムリソースタイプを使っていて、ResEdit プラグインで簡単に編集できた
https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
ファイルタイプ、creator code、ロック、invisible、bozo ビットなどは常にファイルシステムに保存されていた
例えば MFS ディスク形式の説明を見るとよい: https://wiki.osdev.org/MFS#File_Directory_Blocks
Mac 起動 DVD を作るのも、それなりに手ごわかった
以前は
.DS_Storeの生成を無効にする方法があったと記憶しているが、Apple がそれをなくしてしまい、なぜそんな変更をしたのかまったく理解できない結局、ファイルシステム全体を監視して
.DS_Storeが作られた瞬間に削除するプログラムまで自分で書いた[0] https://github.com/slmjkdbtl/dskill
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUEhttps://support.apple.com/en-us/102064
ローカルボリュームで無効にする方法があった記憶はない
.で始まるファイルを作り始めて、本当にめちゃくちゃにした.DS_Storeが許可されてからは、ほかのエンジニアたちも.fseventsd、.Spotlight-V100のようなものを簡単に承認したように見えるこうしたファイルのせいで「汚染された」ファイルシステムをどれだけ見てきたか分からない。主に SD カードや USB フラッシュドライブだったが、時にははるかにひどい場合もあった
たいていこういう状況では
rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100を実行し、何かがさらに書き込まれる前に素早くドライブを取り出す特に状態が悪化しているディスクからデータをコピーしなければならないとき、最も望ましくないのは全体のインデックス作成を始めてディスクに書き込むことだ
本当に、こういうものには 設定オプション があるべきだ
find / -name ".DS_Store" -exec rm {} \; 2>/dev/nullこれをスクリプトに入れて
crontabに追加すればよい.DS_Storeは本当に不運な設計に見える。目的はあり、回避策もいろいろあるが、現実には遭遇する人の99%にとってファイルのゴミをまき散らす存在になってしまったユーザー体験の仕上げという面では Apple らしくない
System 7.5、OS X、Windows を併用して育ったが、Mac は不要なファイルやファイル形式、「コンピューターが内部でどう動いているか」といった実装の詳細を、わざわざ見せない方向だった
だからこのファイルがあちこちにできるのは、Mac に対する自分のメンタルモデルとあまりにも合わず、奇妙に感じる
.DS_Storeファイルを絶対に目にしないFinder は隠しファイル表示をオンにしても、今ではそれらを表示しない
ただし Mac から Windows ユーザーにファイルを共有するときは本当に見苦しく、Mac に乗り換えようか考えている人に悪い第一印象を与えかねないと思う
なぜ同じフォルダ内に置かれなければならないのか理解できない。OS がどこかに独自の小さなデータベースを持ち、各パスを参照するのではだめなのか？
「ユーザーが表示設定を実際に調整したり、フォルダ内のアイコン位置を手動で決めたりしたときだけ生成されるべきだ」という意見に同意する。だが実際には、フォルダを訪問するだけで
.DS_Storeが作られるのがほぼ確実だこれが Finder に対する最大の不満だ
Classic Mac OS Finder のように、個々のフォルダウィンドウの見た目やサイズをさまざまにカスタマイズできるのは本当に良い機能だ
しかし同じフォルダをブラウザウィンドウで通り過ぎるだけで、何も変えていないのに、そのカスタマイズの大半がブラウザウィンドウの設定で上書きされてしまう
こんなに簡単に壊れるなら、優れたカスタマイズを許可する意味がない
グローバルショートカットで Applications フォルダを開いているが、そのウィンドウの見た目を整えたくても意味がない。ショートカットを押すたびに何を見ることになるか分からず、何度も初期化される
理由は、Finder にデフォルトのブラウザウィンドウ構成を設定する方法がないからだ。その代わり、訪問する各フォルダに現在のブラウザ設定を残していくので、本当にいらだたしい
最後に置いておいた姿そのままで同じウィンドウが前面に飛び出してくるのは本当に良かったし、懐かしい
cmd-shift-Aで Applications フォルダを開け、cmd-shift-Uで Utilities フォルダを開けるMac ユーザーではないので、GitHub などから入手した
.tgzの中に.DS_Storeが大量に入っていると、いつも少しイラッとするmacOS はおそらく GNU
tarを使っているのだと思うが、デフォルトで.DS_Storeを無視するように修正または設定していないのは、かなり意外だCOPYFILE_DISABLE=trueをエクスポートすると、tarが.DS_Storeファイルをスキップするネットワークボリュームを閲覧するときに
.DS_Storeファイルの生成をデフォルトでオフにする方法は、言及する価値がある。そうしないと Finder で見て回るだけでディレクトリの更新時刻が変わるが、これは本当に最悪だhttps://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...
.DS_Storeがあるか見たときはなさそうだったのに、ターミナルに行くと実際には存在していたもう Finder の隠しファイル表示機能は信用できない。すべての隠しファイルを表示するのではなく、ユーザーが気にすべきだと Finder が判断した隠しファイルだけを表示するからだ
自分のネットワーク共有はローカルの Synology なので大きな問題ではないが、職場ではこうしたファイルがかなりごちゃごちゃした状況を作っていた
ドットアンダースコア（
._）ファイルもある。ネットワーク共有でこうしたファイルが作られないように無効化する方法はあるのだろうか？[0] https://superuser.com/questions/212896/is-there-any-way-to-p...
幸い Emacs のファイルマネージャー Dired を使えば、この厄介な小さなファイルや LaTeX の実行が生成するファイルを簡単に見なかったことにできる
(setq dired-omit-mode tdired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")