重複ファイルの整理の手順|走らせる前に決める3つのこと
重複ファイルの整理で手が止まるのは、スキャンの最中ではありません。結果の一覧が出たあと、どれを消してよいのか判断できずに閉じてしまう場面です。原因は作業の順番にあります。ここでは、走らせる前に決めておく3つのことから、削除後の確認までを、実際に測った所要時間つきで順に並べます。
走らせる前に決める1つ目は、残す側の条件
重複の一覧を前にして「どれを消すか」を1件ずつ考え始めると、数千行の途中で判断が変わります。先に決めるのは消す側ではなく、残す側の条件です。条件は次のどれか1つに寄せておくと、あとの作業が機械的になります。
- 決めた保管場所にあるほうを残す。ダウンロードフォルダと資料フォルダに同じものがあるなら、資料フォルダ側を残す
- 階層が浅いほうを残す。深い場所にあるものは、展開や一時的な作業でできた副産物であることが多い
- 作成日が古いほうを残す。もとの1本を正として、あとから増えた分を落とす
- 変更日が新しいほうを残す。編集が進んでいる側を正とする場合に選ぶ
3番目と4番目は同時には成り立ちません。中身が同じでも日付は食い違うため、どちらを正にするかで残るファイルが変わります。この1点を先に決めておかないと、一覧の途中で基準が揺れます。
決めた条件は、頭の中に置かず短い文にして書き出しておきます。「資料フォルダにあるほうを残す。どちらも資料フォルダに無い場合は、階層が浅いほうを残す」といった具合に、例外まで含めて2行ほどで書けるなら十分です。この2行があると、一覧を上から処理するときに迷いが出た行だけを保留にでき、残りは止まらずに進みます。書き出していない場合、迷いが出るたびに条件そのものを作り直すことになり、それが数千行の途中で起きます。
決められない組が出てきたときの扱いも、あらかじめ決めておきます。判断がつかない組は、削除ではなく別のフォルダへまとめて移しておき、あとから見直す。この逃げ道を先に用意しておくと、1つの組で悩んで全体が止まる事態を避けられます。
2つ目は、走らせる範囲と、外す場所
範囲を絞らずにホームフォルダ全体へ掛けると、消してはいけないものが大量に一覧へ上がってきます。最初から外しておく場所は、おおむね決まっています。
| 外す対象 | 理由 |
|---|---|
| ライブラリフォルダ | アプリの設定と作業用データが入っており、同一の中身が正常に複数存在する |
| 写真ライブラリやアプリ本体などのパッケージ | 内部のファイルを外から消すと壊れる |
| 開発用の依存パッケージのフォルダ | 同じ部品が複数のプロジェクトに置かれるのは設計どおり |
| バージョン管理の内部データ | 履歴の実体が入っており、同一内容が意味を持って重複する |
| クラウド同期フォルダの未ダウンロード分 | 中身を読もうとした時点で実体のダウンロードが始まり、通信量と時間がかかる |
最後の1行は見落としやすい箇所です。ストレージ最適化を有効にしていると、手元には実体のないファイルが並んでいます。中身を比べる処理はファイルを開くため、スキャンをきっかけに数十GBの取得が始まることがあります。範囲に入れるのであれば、実体が手元にある状態にしてから走らせることになります。
範囲の決め方には、もうひとつ順番の問題があります。複数のディスクや同期フォルダをまたいで一度に走らせると、「ノートPCの中と外付けディスクに同じものがある」という結果が大量に出ます。これは多くの場合、重複ではなく意図した控えです。最初の1回は、ダウンロードフォルダ、デスクトップ、書類フォルダといった1つのディスク内の作業領域だけに絞り、ディスクをまたぐ比較は目的が固まってから別に走らせるほうが、判断する量が減ります。
範囲を書き出しておくことも、あとで効いてきます。対象にしたフォルダと外したフォルダを記録しておけば、次に走らせるときに同じ条件で比べられます。記録が無いと、前回より件数が増えたのか、範囲を広げたから増えて見えるだけなのかが分かりません。
3つ目は、絞り込みを何段に分けるか
中身を突き合わせる処理は、全ファイルのハッシュを取る必要はありません。先に安い判定で候補を削ると、読む量が大きく減ります。31,263本・91GBのフォルダで、3段に分けて測った結果が次の通りです。
| 段 | 判定の内容 | 残った本数 | 所要時間 |
|---|---|---|---|
| 1段目 | ファイルサイズが一致するか | 24,998本 | 約1秒 |
| 2段目 | 先頭64KBのハッシュが一致するか | 23,379本 | 3.7秒 |
| 3段目 | 全文のハッシュが一致するか | 5,305群 | 11.3秒 |
1段目で6,252本が候補から外れました。サイズの取得はファイルを開かずに済むため、ここは通信も読み込みも発生しません。3段目で実際に読んだのは17.98GBで、フォルダ全体の2割ほどです。合計の所要時間は約16秒でした。
段を分けずに全ファイルの全文ハッシュを取ると、読む量は91GBになります。所要時間が5倍前後に伸びるうえ、外付けディスクやネットワーク越しのフォルダでは差がさらに開きます。市販のアプリが「速い」と書いているとき、その中身はたいていこの段分けです。
2段目の効き方は、扱っているファイルの種類で変わります。今回の測定では24,998本から23,379本にしか減りませんでした。先頭の数十KBが同じで中身が違うファイルが多かったためで、同じ形式の書き出しや同じテンプレートから作った資料が並んでいると、この段はあまり働きません。逆に、動画や仮想ディスクのような大きいファイルが多い場合は、先頭だけを読んで落とせる本数の効果が大きく出ます。自分のフォルダでどちらの傾向かは、1段目と2段目の残り本数を見れば分かります。差が小さいなら2段目は省き、1段目から全文に進んだほうが単純です。
段の順番を入れ替えないことも条件のひとつです。サイズの判定はファイルの情報を読むだけなので、ディスクにもネットワークにも負担をかけません。ハッシュの計算はファイルの中身を読みます。安いほうを先に置くという順番を崩すと、段に分けた意味がなくなります。
The Coreutils Gotchas contains a list of some quirks and unexpected behaviour (which are often mistaken for bugs). 出典: gnu.org
段分けを自分で組む場合、つまずくのはハッシュの計算ではなく、ファイル名の受け渡しです。空白や括弧や日本語を含む名前がコマンドの引数として切れてしまう事故は、手順を組んだ初日にほぼ確実に起きます。区切り文字を空白ではなくヌル文字にして受け渡す形にしておくと、この種類の失敗が消えます。
消す前に、必ず下見の一覧を作る
3段目まで通った結果は、そのまま削除に流さず、いったんファイルに書き出します。画面の一覧をスクロールしながら判断すると、どこまで見たかを見失います。
書き出す一覧に入れておくのは次の5つです。組の番号、残す側のパス、消す側のパス、1件あたりのサイズ、その組で戻る容量。表計算ソフトで開けば、サイズの大きい順に並べ替えられます。
並べ替えたあとの扱い方は、上から数十行と、それ以降で変えることになります。実測では、重なっていた本数が18,054本に対して容量は9.53GBでした。1本あたりの平均は0.5MB前後で、上位の数十件が容量の大半を占めます。空き容量を戻すのが目的なら、上位だけを見れば足ります。フォルダを見通しよくするのが目的なら、小さいファイルの群をフォルダ単位でまとめて扱うことになります。1件ずつ判断する対象ではありません。
削除はゴミ箱を経由させる
下見の一覧に納得したら、削除に移ります。このとき、いきなり完全削除にしないことが復旧の余地を残します。ゴミ箱に入れておけば、参照が切れたアプリが出てきたときに戻せます。
ゴミ箱を空にするのは、削除の当日ではなく、数日から1週間ほど通常どおり作業してからにします。重複だと思って消したファイルが、実際には何かに参照されていた場合、その不具合は削除の直後ではなく、次にそのアプリや作業を開いたときに出ます。
戻せる状態を保つために、削除の直前に一覧のファイルをもう1部とっておくことも有効です。ゴミ箱の中身は名前だけが並び、どのファイルがどの組の片割れだったのかが分かりません。組の番号と両方のパスを書いた一覧が手元にあれば、戻すときに元の場所へ正しく置き直せます。
外付けディスクとネットワーク上のフォルダは扱いが別です。外付けディスクのゴミ箱はそのディスク上に作られるため、空き容量は捨てただけでは戻りません。ネットワーク上のフォルダは、そもそもゴミ箱を経由せず即時削除になる場合があります。この2か所を対象に含めるなら、削除ではなく別の場所への移動にしておくほうが安全です。
結果はレポートではなく、空き容量で確かめる
削除を実行したあと、道具が表示する「回収した容量」の数字をそのまま受け取らないことが最後の手順です。
確かめ方は単純で、削除の前後でディスクの空き容量を記録し、その差を見ます。表示された回収量と実際の増分が食い違う理由は、主に2つあります。ひとつは、消した相手がAPFSのクローンで、もともと領域を持っていなかった場合。もうひとつは、削除した領域がローカルスナップショットに保持されていて、まだ解放されていない場合です。後者は時間が経てば解放されるので、当日の値と数日後の値を両方見ておくと切り分けられます。
差が大きいときに次の操作へ進まないことも大事です。空き容量が増えていないのに削除だけを重ねると、消した本数だけが積み上がります。原因を1つ確かめてから次へ進むと、以降の判断がすべて変わります。クローンが多いフォルダだと分かったなら、そのフォルダで重複を消しても容量の目的は達成できないので、対象を別の場所へ移すことになります。
確かめた値は、範囲の記録と一緒に残しておきます。次に走らせたときに、前回からどれだけ増えたかが分かるためです。増え方が分かれば、整理の頻度も決まります。
同じ作業を繰り返さないために、入口を減らす
重複ファイルの整理は、一度やれば終わる作業ではありません。実測したフォルダの重なりは、数年かけて溜まったものではなく、日々の受け取りと展開の積み重ねでできています。次に同じ状態へ戻らないようにするには、増える入口のほうを減らします。
やることは3つです。受け取り先をダウンロードフォルダ1か所に寄せる。圧縮ファイルを展開する場所を、保管場所ではなく作業用のフォルダに固定する。同じ資料を複数の場所へ置かず、必要なら参照だけを置く。
道具の側でこの流れを短くできるかどうかは、検出と確認と削除を同じ画面で完結できるかで決まります。ファイル一覧の上で直接コマンドを走らせて中身を確かめられる構成かどうかは、できることにまとまっている操作の範囲から読み取れます。フォルダとターミナルとAIが同じ窓にあるなら、下見の一覧を作る段と削除する段でアプリを行き来する必要がなくなります。
判定の方式や対象にできる場所の違いを横に並べて確かめたい場合は他のファイル管理との比較が、導入にかかる費用を先に見積もりたい場合は料金が目安になります。外付けディスクや同期フォルダを対象にできるかといった個別の条件はよくある質問で確認できます。手順そのものはどの道具でも変わりません。残す条件を決め、範囲を決め、段を分けて絞り、下見を作り、ゴミ箱を経由し、空き容量で確かめる。この順番を崩さないことが、一覧を前にして手が止まらない条件です。
よくある質問
重複ファイルの整理は、どこから手をつけるのが早いですか?
残す側の条件を決めることからです。決めた保管場所にあるほうを残す、階層が浅いほうを残す、といった条件を1つに絞っておくと、一覧が数千行になっても判断が機械的になります。消す側を1件ずつ考える進め方にすると、途中で基準が揺れて作業が止まります。
スキャンに時間がかかりすぎます。短くする方法はありますか?
絞り込みを段に分けてください。サイズの一致で候補を削り、次に先頭64KBのハッシュ、最後に全文のハッシュという順にすると、実測では31,263本のフォルダで合計約16秒でした。全ファイルの全文ハッシュを取ると読む量が5倍近くになります。
スキャンから外しておくべき場所はどこですか?
ライブラリフォルダ、写真ライブラリやアプリ本体などのパッケージ、開発用の依存パッケージ、バージョン管理の内部データです。これらは同一内容が正常に複数存在する場所で、外から消すと壊れます。クラウド同期の未ダウンロード分も、スキャンが実体の取得を始めるため外しておくのが無難です。
削除したのにアプリの表示する回収容量と空き容量が合いません。
消した相手がAPFSのクローンで、もともと領域を持っていなかったか、削除した領域がローカルスナップショットに保持されていてまだ解放されていないかのどちらかです。後者は時間が経つと解放されるので、削除当日の空き容量と数日後の値を両方記録しておくと切り分けられます。