なぜクロスプラットフォームのNAS復元時に大文字・小文字のみのファイル名が衝突するのですか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

大文字小文字のみのファイル名の競合は、バックアップに復元先が同等とみなす2つのパスが含まれている場合に、クロスプラットフォームのNAS復元中に発生します。Linuxホームサーバーはこれを保持することがあります Photo.jpg および photo.jpg 別々のファイルとして扱われる一方で、Windowsボリューム、デフォルトのmacOSボリューム、またはSMBクライアントはそれらの名前を1つの宛先として扱うことがあります。復元ツールはその場合、上書き、名前変更、スキップ、マージ、または停止を行う必要があります。

どのパスが衝突し、ツールがそれらをどのように処理したかを把握するまで、完全な復元を続行しないでください。影響を受けたツリーを隔離されたステージング場所に復元し、両方のソースオブジェクトを決定論的な一時名で保持し、パスマッピング記録を作成してからデータをライブNAS共有に移動してください。

なぜバックアップは復元先が拒否する2つの名前を保存できるのか?

バックアップリポジトリは、宛先ファイルシステムの比較ルールを強制せずにパスを不透明な名前として記録できます。Linuxファイルシステムは大文字と小文字を区別することが多い一方、WindowsやデフォルトのmacOSファイルシステムは入力された大文字小文字を保持しつつも、大文字小文字を区別せずに名前を比較することが一般的です。クロスプラットフォームの復元に関する議論では、バックアップ内のソースパスは有効でも復元先のシステムで表現できない場合があることが示されています。

ホームNASでは、Linuxコンテナのボリューム、開発者ディレクトリ、写真のインポートツリー、メディアライブラリをWindowsやmacOSからアクセスする共有に復元した後に、これがよく起こります。バックアップが必ずしも破損しているわけではなく、宛先の名前空間に区別される名前の数が少ないだけです。

大文字小文字を保持するSMBは、大文字小文字を区別するストレージとは異なります

SMB共有は元の大文字小文字を表示しつつ、大文字小文字を区別しない検索を行うことがあります。TrueNASコミュニティの例では、データセット層とSMBアクセス層で異なる大文字小文字のルールが説明されています。そのため、サーバーは混在した大文字小文字の名前をローカルに保存していても、WindowsやmacOSのSMBクライアントはそれらを別々のオブジェクトとして扱えないことがあります。

NASファイルシステムの設定だけでなく、実際の復元パスをテストしてください。復元ジョブで使用するのと同じクライアント、プロトコル、マウント、宛先ディレクトリを通じて、大文字小文字の違いだけで名前が異なる2つの無害なファイルを作成します。2つ目の作成が失敗するか最初のファイルに解決される場合、そのパスは元のツリーを安全に受け入れられません。

フォルダ名の衝突はサブツリー全体をマージする可能性がある

衝突は最終ファイル名だけでなく、任意のディレクトリコンポーネントで発生する可能性があります。バックアップにPhotos/2025/A.jpgphotos/2025/B.jpgが含まれている場合、大文字小文字を区別しない宛先は両方のブランチを1つのディレクトリにマージするか、2番目のブランチを拒否するかもしれません。LinuxとWindowsの混在転送アカウントは、ディレクトリコンポーネントの衝突がファイルの誤配置や破棄を引き起こす例を示しています。

宛先の大文字小文字変換ルールを適用した後の完全な相対パスを比較してください。ベース名の重複だけをチェックするレポートは、親ディレクトリによって作成される衝突を見逃す可能性があります。

復元ツールはすべての衝突を安全に処理できるわけではない

復元アプリケーションは「すでに存在します」エラーで停止する場合や、接尾辞を追加する場合、最初のファイルを保持する場合、最後のファイルを保持する場合、またはディレクトリツリーをマージする場合があります。衝突ペアの一方がスキップされても、ジョブが成功または警告状態で終了することがあります。大文字小文字の区別によるファイル名衝突の不整合な処理に関する研究は、ツールの動作を仮定せず観察する必要がある理由を示しています。

大規模な復元の前に、大文字小文字の違いだけで異なるファイルとディレクトリのペアを含む小さなテストバックアップを作成します。ツールが失敗するか、名前を変更するか、上書きするか、マージするかを記録し、その後両方のコンテンツハッシュを検証してください。

Unicode正規化による類似の衝突が発生する可能性

2つのファイル名は、合成済みのアクセント付き文字と基本文字に結合文字が続くなど、異なるUnicodeコードポイントのシーケンスを使いながら見た目は同一に見えることがあります。APFSの名前処理は一部のモードで正規化された比較を使用しつつ形式を保持し、ファイル名検索における大文字小文字の区別とUnicode正規化の相互作用があります。

すべての見かけ上の大文字・小文字のみの衝突が大文字・小文字の違いだけによるとは限りません。アクセント付き文字、アジア言語、または視覚的に同一の名前が関係する場合は、名前をエスケープまたはコードポイント対応形式でエクスポートしてください。

復元を一時停止し、両方のオブジェクトをまず保持する

衝突が発生した場合は、ライブの宛先への復元を停止してください。上書き有効で同じジョブを繰り返し実行しないでください。勝者はトラバーサル順序によって変わる可能性があります。大文字・小文字を区別するステージングファイルシステムを作成するか、両方の名前を表現できるLinux環境を通じて復元してください。Windowsのコマンドライン記事では、大文字・小文字を区別するディレクトリが通常のWindowsアプリケーションでは区別できない名前を保持できることを説明しており、ステージングが両方のオブジェクトを表現できる名前空間を使う必要がある理由を示しています。

衝突する各オブジェクトを、例えば以下のような一意の一時名に復元します。 Photo.jpg.__case1 および photo.jpg.__case2元のパス、バックアップバージョン、サイズ、チェックサム、および選択した一時名をCSVまたはJSONのマッピングファイルに保持します。

ライブ共有に移動する前に衝突を決定的にリネームする

どのファイルが最初に見つかるかに依存しないルールを選択してください。拡張子を保持しつつ、ソースプラットフォームのラベル、安定したハッシュ断片、または明示的なシーケンスを追加します。例えば、以下のように保持します。 Photo__linux_A1B2.jpg および photo__linux_C3D4.jpg 意味が不明確な自動「コピー」サフィックスを受け入れるのではなく。

バックアップリポジトリや元のソースで名前を変更する前にマッピングを確認してください。ZimaSpaceのプラットフォーム間コピー前の大文字・小文字を区別するファイル名の衝突検出ガイドを使って、再構築されたステージングツリーをスキャンし、未解決のペアが残っていないことを確認できます。

ファイル名変更後のアプリケーション参照の修復

名前変更されたメディアファイルはライブラリデータベースから消え、コンテナ設定は古いパスを指し、写真アプリは名前変更されたオブジェクトを新しい資産として扱うかもしれません。まずデータを復元し、その後プレイリスト、サイドカーリンク、スクリプト、データベースレコード、バインドマウント、正確な綴りに依存するアプリケーションインデックスを更新してください。

セルフホスト型アプリケーションの場合、元のパスを記述するデータベースと設定を保持してください。ファイルシステムのみの復元はすべてのバイトを保持できますが、パス参照が一致しなくなるとアプリケーションは不完全なままになります。

衝突レポートを使って復旧アクションを決定する

観察された結果 考えられる原因 安全な復旧アクション
2つ目のファイルが「すでに存在します」と報告する 復元先は名前を大文字・小文字を区別せずに比較する 両方を大文字・小文字区別のステージングに復元し、決定論的に名前を変更する
2つのソースフォルダが1つに見える 親ディレクトリが大文字・小文字のみで異なる 正規化された完全なパスを比較し、統合されたサブツリーを分割する
復元は完了したがオブジェクト数が少ない ツールが衝突メンバーの一方をスキップまたは上書きした 衝突ログを確認し、パスの在庫とハッシュを比較する
名前は同じに見えるが大文字・小文字が異なるものが存在しない Unicode正規化またはサポートされていない文字 エスケープされたコードポイントを検査し、ステージングで正規化する
ファイルは存在するがアプリが見つけられない 名前変更により正確なパス参照が壊れた アプリケーションのメタデータ、インデックス、コンテナマウントを更新する

よくある質問

SMB共有は両方を保持できますか? File.txt および file.txt?

基盤となるデータセット、SMBサーバー設定、クライアント、アプリケーションがすべて互換性のある大文字・小文字区別のセマンティクスを使用している場合のみです。大文字・小文字区別のNASデータセットだけでは、すべてのSMBクライアントが両方の名前を作成・参照できることを証明しません。

大文字・小文字を区別するAPFSボリュームに復元すればすべての衝突が解決しますか?

いいえ。大文字・小文字のみのペアは保持できますが、その後のSMB復元先、Windowsクライアント、アプリケーション、アーカイブ形式、またはUnicode比較ルールが名前を統合または拒否する可能性があります。

なぜ見た目が同じファイル名でも衝突するのでしょうか?

異なるUnicodeシーケンスを使用していても、復元先が同じ比較形式に正規化する場合があります。FinderやExplorerの表示だけに頼らず、コードポイントを検査してください。

最終的な結論

大文字・小文字のみのファイル名の衝突は、バックアップがクロスプラットフォームの復元先よりも多くの異なるパス名を保持できるために発生します。最初の衝突で停止し、互換性のあるステージングエリアに復元し、すべてのオブジェクトを決定論的な一時名で保持し、マッピングを記録し、データをライブのホームNAS共有にインポートする前にカウントとチェックサムを検証します。

サポートとヒント

もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Aug 17, 2026

Plexは別のDockerコンテナとGPUを共有できますか?

Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.