ホームディレクトリを構造化するためのヒント（2023年）
(unixdigest.com)ホームディレクトリ構造のヒント
- ディレクトリの構造化や整理は、他の物事の構造化や整理と大きくは変わらず、自分にとって最も理にかなった方法で行うことが重要
- 整理を扱う際は、非常に短時間で手に負えない状態になりうる
- 整理の主な目的は効率性であり、探したいものを簡単かつ素早く見つけられ、保存すべきものを簡単かつ素早く保存できる必要がある
隠し標準ファイルとディレクトリ
- 自分のホームディレクトリには、
.config、.aliases、.profile、.gnupg、.mozillaなど、現代の Unix 系オペレーティングシステムの一部である標準的な隠しファイルが一通りある - すべてのアプリケーションが XDG_CONFIG_HOME を尊重してくれるのが望ましいが、その点にあまり干渉したり気にしすぎたりはしない
- 以前は Git で $HOME を管理しており、これは Dotfiles を構成する優れた方法
- 変更履歴を維持するため、今でもすべての Dotfiles を Git に入れているが、利用しているさまざまなシステムで同じように動作する Dotfiles だけをそのまま残している
- 設定ごとの Dotfiles は
dotfilesディレクトリに保管し、シンボリックリンクを使う
一般的なファイルおよびディレクトリの構成
- 一般的なファイルとディレクトリは、主に「カテゴリ」と「日付」の2つの方法で構成する
- 基本ディレクトリ構造:
bindataedatamntusr/dotfiles
DesktopとDownloadsディレクトリはそのままにしている（ほとんどのアプリケーションがそれを前提にしているようなので）binディレクトリにはシェルスクリプトと個人用バイナリ実行ファイルを保管する（パッケージマネージャー経由でインストールしたものは除く）mntディレクトリは、SD カード、USB ディスク、ホームラボで使う共有ストレージなど、さまざまなマウントポイントに使う- 自動マウントは決して使わず、マウント用のシェルスクリプトを使う
usr/dotfilesディレクトリは.aliasesのような一般的な Dotfiles とともに Git で管理し、dotfilesディレクトリ内の関連ファイルへのシンボリックリンクを使う
データディレクトリの構成
dataとedataディレクトリは、すべての資料を保管する2つの主要ディレクトリ- この2つのディレクトリは、ルートインストールとは別に、ディスクミラーリングプール上で動作する ZFS データセット
- ZFS を活用し、スナップショットや ZFS の send / receive を定期的に使って、ネットワークストレージへ簡単にバックアップしている
dataとedataの違いは、edataが ZFS のネイティブ暗号化データセットである点- 暗号化はプライバシーに有効だが、すでに複雑なファイルシステム階層の上にさらに厄介な複雑さの層を重ねるものであり、ZFS の暗号化にはバグもある
- 重要なデータは、常に複数の異なる保存手段と場所にバックアップすることを強く推奨する
- 重要なものにはクラウドストレージを使わない
追加のヒント
- ファイル名およびディレクトリ名の基本ルールは、名前を見るだけでそれが何かを簡単に識別できるようにすること
- ファイルを開いてみないとそのファイルが何についてのものかわからないなら、すぐに開いて確認し、次にそのファイル名を見たときにより意味のある名前へ変更すべき
- ファイルやディレクトリを整理せず放置すると、後から修正するのが非常に難しくなる
- ファイルを開かなくても内容を把握できるよう、必要に応じて長い説明を含んだファイル名を使う
GN⁺の意見
-
この記事は、ディレクトリ構造を整理し構成する方法について実用的なヒントを提供している。特に ZFS データセットを活用して、暗号化されたディレクトリと暗号化されていないディレクトリを分けて管理する方法が興味深い。
-
個人的には、重要なデータは暗号化して保管するのがよいと考える。ただし、暗号化による性能低下や複雑性の増加といった欠点もあるため、状況に応じて選択的に使うのがよさそうだ。
-
また、暗号化されたデータへのアクセス方法を家族と共有しておくことも重要なポイントだと思う。事故などで自分がアクセスできなくなったとしても、データを失わないようにする必要がある。
-
個人データ管理のためには、著者のように体系的なバックアップ戦略を立てることが非常に重要。321 バックアップルールに従いつつ、クラウドストレージよりも物理的に分散したローカルストレージを活用するのもよい方法に見える。
-
個人データ整理に役立つオープンソースツールとしては、Syncthing や Nextcloud などがある。こうしたツールをうまく活用すれば、体系的で安全な個人データ管理が可能になるだろう。
1件のコメント
Hacker News の意見
ホームディレクトリが散らかるのが嫌で、特にアプリがホームに隠しでもないディレクトリを作る必要があると思っていると、本当に腹が立つ。
いちばん腹立たしいのは Go モジュールのデフォルトディレクトリである
~/go。あまりに嫌で、何年も Go アプリのインストールや開発を避けていたが、結局使わざるを得なかった。GOPATHの設定で変更はできるものの、デフォルトとしてはひどい。.rustup、.mix、.npm、.yarnのような独自ディレクトリでドットファイルを汚していく。それでも
~/goのように、隠す礼儀すらなくホームディレクトリを汚染するのは本当に無礼だ。自分のプロジェクト整理のやり方とあまりに合わず、Go に関心を持たなくなった主な理由だった。複数の無関係なプロジェクトを 1 つのモノレポにまとめておくのが好きな人にはより合うのかもしれないが、自分の好みではない。
$HOMEに置かないこと。$HOMEはアプリが汚す場所であり、自分のファイルは文字どおりそれ以外のどこかに置けばよい。.vimrcと.gitconfigは Git リポジトリへシンボリックリンクしてある。そうすれば、ホームディレクトリの残りが完全にゴミでも構わないし、マシンが死んでも別のマシンで数分以内に復旧できる。ほとんどのアプリがホームディレクトリにファイルをばらまく問題を減らすのに、xdg-ninja が役立った。
要するに、インストール済みのプログラムをスキャンし、XDG 標準に従うよう設定できるかどうかを教えてくれる。すべてに効くわけではないが、多くのアプリにはそうしたオプションがある。
https://github.com/b3nj5m1n/xdg-ninja
整理だけでなく、マシン間で簡潔にバックアップして移植したい。
.configフォルダは、アプリがそこに数ギガバイトものセッションデータを入れてしまうため、戦略的にバックアップするうえで大きな悩みの種になる。「セッションデータ」は「設定」ではない。アプリの「設定」が数ギガバイトもあるはずがないだろう。
.configは読み取り専用でも動作できるべきだ。.configをアプリデータ保存場所のように使うのか分からない。そういう用途には.localと.cacheがある。これはあまりに個人的なものなので、筆者の解決策は自分には役に立たないし、自分の解決策も他の人にはあまり役に立たないと思う。
自分のホームディレクトリはほとんど空。作業ファイルはすべて OwnCloud にあり、本当の問いは OwnCloud 内のディレクトリ構造をどうするかだ。ローカルの Git リポジトリは完全に別パーティションに置いている。
今では KeepassXC が SSH キーを扱ってくれるので、
.sshのキーも OwnCloud にある Keepass ファイルの中に入った。ものすごく単純になり、もうホームディレクトリには本当に気にするようなものがほとんどない。ログイン後、コマンド 1 つで、今いる環境が Linux なのか、仕事用なのか、個人用なのか、デスクトップなのか、サーバーなのかに応じたファイルセットを同期できるべきだ。
たとえばホーム vault のエンドポイントや特定のトークンのような環境変数は、仕事用システムには絶対に持ち込みたくない。
最近 NixOS プロジェクトの home-manager に移行したが、かなり有望に見える。Nix 言語は複雑だが、さまざまな環境を定義する抽象化こそ必要としていたもので、Git ブランチで仕事用／個人用ファイルの内容を分けられる。
.vimrcと.bashrc/.zshrcはホームに置いているアイデア自体は悪くないが、メディアを家族のような構造に分けるやり方は気に入らない。あとで重複ファイルや編集済みの重複版が大量にでき、簡単に混ざって編集版を失いそうに見える
写真はEXIFキーワードで整理するほうがよいと思う。写真そのもの、おそらくMIMEタイプ内にメタデータを保存し、家族関連なら
#familyや#personxのようにタグを付ければよい。だから写真は日付別のようなフォルダに置き、残りはAdobe Bridgeのようなプログラムでキーワードを編集する文書ファイル名の構造は、
Date then Description.txtとKeyword Title or Description and then Date.txtの両方を使ってみた。日付はソートのためにYYYY-MM-DD-hhmm形式のISO日付を使い、-hhmmは任意場合によっては主題、つまりキーワードやタイトルで並べたいが、ログのようにいつ記録したかのほうが重要なときは、日付を先頭に置くのがよい
日付はシステムにも保存されるので不要に見えるかもしれないが、ファイルを移動していると日付はいずれ変わるし、ミスをすればもっと簡単に変わる。一方、ファイル名の中の日付は変わらず、一覧のソートにも役立つ
photoprismとphotostructureはディレクトリ構造や整理にあまりこだわらないようだが、paperless（-ngxなどの新しい派生を含む）は整理へのこだわりが強く、既存構造を尊重しようとしないことで悪名高い
しばらく写真にcamlistore/perkeepを使っていたが、Google Photosには、すべての写真に誰が写っているか、年齢差まで考慮して見分ける圧倒的な機能がある。8歳差の息子2人は同じくらいの年齢のころ本当に似ているのに、誰が誰かを正確に区別する。顔分析を使っているのか写真のメタデータを使っているのかはわからないが、一度も取り違えたことがない。ただし、そのタグ情報をGoogle Photosの外へまともに取り出す方法がなく、お金を払っているのにそうなのだ
そろそろ改めて見直す時期だと思う。photostructureやphotoprismが顔認識を試みているか覚えていないが、まだであっても近いうちにGoogle Photosに近いレベルになるか、少なくともGoogle依存を断てるくらいには良くなると思う
文書と写真/動画はよいとして、音楽はどうだろう。良くも悪くも、音楽コレクションをファイルとして直接管理しなくなって少なくとも10年ほどになる。最近はpaperlessやphotoprismのように、単なる「ディスク上のファイル」よりもコンテンツとより深く統合された音楽用ライブラリシステムはあるのだろうか？
私のやり方はこうだ
GUI関連の項目は大文字、CLI関連の項目は小文字にしている。
~/documentsのようなほうが好みだが、GUI側の人たちが大文字にこだわるので、そのまま受け入れている。両者を混ぜる必要はほとんどないので大きな問題ではない~/dotfilesはGitで管理しているドットファイル用ディレクトリ。~/.zshrc -> dotfiles/zshrcのようにシンボリックリンクを作る。専用の管理ソフトウェアは使わず、単にリンクを作るだけ。以前は~/.dotfilesを使っていたが、見える場所に置くほうが理にかなっていると思う~/projectsはプロジェクト用ディレクトリ。~/projects/testは確認用の使い捨てテストプロジェクト、~/projects/myは個人プロジェクト、~/projects/companyは現在働いている会社のプロジェクト。フリーランスに近い形で複数の会社と仕事をすることがあるので、分ける必要がある~/tmpはすべての使い捨て作業用ディレクトリ。mkcdtmpというシェル関数を用意し、~/tmp/240419のように現在の日付のディレクトリを作って、その中へ移動する。本当に良いやり方だ。大きなディスクを買って、ゴミをある程度整理されたまま残しておくほうが好みなので、ほとんど掃除しない。昨日や先月の何かが必要になったらどこにあるかわかるし、一時作業の整理で最も役に立ったことだ。必要なら~/tmp/whateverも作れるし、どうせ全部捨てるものだ~/Desktopは使わない。~/Documentsもほとんど使っておらず、まだ整理方法を見つける必要がある。短いメモのようなものは、個人WebサイトをビルドするGitHubリポジトリに放り込んでいる。いくつものメモアプリを試したが、Markdownでできた普通のWebサイトが自分には一番合っていた作業を非常に構造化して整理することに成功したことはない。いつもゴミの山があちこちに転がり、最終的に使える何かになるので、自分自身と戦う代わりに、そのゴミを整理されたゴミにすることにした
本質的に、私のコンピュータは消耗品だ。
~/projectsのすべてはGitにあり、~/tmpはあまり重要ではないキャッシュや廃棄作業に近い。クリーンな状態から復元するのに時間がかからないよう整理しようとしている。OSを一から頻繁に再インストールし、OSやノートPCもよく替えるが、この方法が一番合っているファイルシステムで大きな不満の1つは、あまりにも多くのディレクトリがDで始まることだ
Desktop、Dev、Downloads、Documents、Dropboxなどなど
何か変えてみようかとも思ったが、筆者が言うように、多くのアプリケーションはこの問題についてかなり頑固だ
/srcを使っているかなりシンプルだが、自分にはよく合う構成を使っている。
projects/の下に2023/、2024/のような年別フォルダを作り、各プロジェクトには0000-something/、0312-other-project/、0419-hn-comment/のように月＋日の接頭辞を付ける。毎年、年別フォルダを作り、長期プロジェクトを上の方に出したいときは
0000を付けるか、日付だけを00にしておく。シンプルで、どのOSでも動く。Linuxでは補助スクリプトを少し使ってはいる。
ダウンロードフォルダからファイルを移す先のディレクトリも素早く作りやすいし、ネストを1段だけに保てば見つけやすい。
YYYY/MM/DDパターンのように月の階層がもう1つ増える方式より良いと思う。最上位ディレクトリには、たいてい今作業中のものを置く。「今日」や「今週」のような概念だ。
その時間枠を外れて保管するときは、たとえば今日なら
041924のような形式のフォルダを作り、その日に作ったファイルをすべてその中へ移す。普通の人間の寿命で考えれば、
2024のような文字列を使う必要はないと思う。2100年まで生きるとも思えないし、2000年以前は関係ないので、24で十分だ。時間は流れ続けるので保管フォルダの数は増えるが、サイズは小さく、見つけやすい。毎日、それほどユニークではない標準的なファイルを作る場合には特にうまく合う。
projects/ | 01.01.2017something/ | 01.01.2024other-project/ | 01.01.2023hn-comment/ | 01.01.2022バックアップについては、Time Machineバックアップで新しいMacをセットアップしようとしたところ、MacがTime Machineバックアップ内の何も見つけられなかったことがある。
Appleサポートに連絡してみると、セットアップ過程でバックアップからインストールする代わりに、Time Machineバックアップを初期化してしまうまれなバグがあると聞いた。
幸いBackblazeを設定していたので助かったが、数百GBを復元するのに非常に長い時間がかかった。
今はTime Machine、Backblaze、iCloudバックアップをすべて使い、たまに全体を
.tgzにまとめてS3へアップロードしている。ファイル名とディレクトリ名でハイフンとアンダースコアのどちらを使うかについては、ハイフンに全面的に同意する。
ターミナルで移動するとき、ハイフンを使うのはとても実用的なので標準になるべきだと思う。アンダースコア入りのファイル名を選ぶために毎回追加の入力をしたり、スペースを処理したりするよりずっと良い。
foo-bar-bazのように付けられ、入力時にShiftを押す必要がない。