Windowsエクスプローラの制限にひっかかった
私の仕事では、色々な人が使っているPCの維持管理もあるので、たまに想定外の使い方をしている人がいて、維持管理に苦労する場面があります。
ファイルの整理にフォルダ階層が何層にもなっていて、しかもフォルダ名、ファイル名が異様に長い状態で使用している人のPCがトラブルを起こしたため、リカバリーする必要に迫られました。とても特殊な仕事をしている人なのでこの使い方を否定することもできません。
IT関係者の視点で言えば、現在のWindowsで使用されているファイルシステムはNTFS（New Technology File System）と呼ばれる方式で、Windows NTから採用された当時は画期的なファイルシステムだったと記憶しています。このNTFSの問題というよりは、Windowsを構成する各種のプログラム（エクスプローラとか）が置き去りになっている為に、NTFSではサポートしているロングパス、ロングネームのファイル名をエクスプローラで扱うと思わぬトラブルに遭遇することがあります。
今回それに相当する課題が降ってきてしまいました。
階層が深いファイルをコピー出来ないWindowsエクスプローラーの仕様の不備
今回、PCのHDDがトラブルを起こしたため、新しいHDDにコピーしたいのですが、ロングパスの問題でコピーができない状態です。沢山のフォルダ階層の奥深くにある長いファイル名のファイルがコピーできません。エクスプローラが対応してないので壊れかけのHDDから救出できないのです。
ファイル名の長さは、対象のフォルダーに対して長過ぎる可能性があります。短いファイル名に変更して実行するか、またはより短いパス名の場所に移動して試してください。
対処方法として結論から先に記すと、7-Zipを使ってこの課題を克服することが出来ました。7-Zipはロングパス・ロングネームに対応しているため、とても長いPATH（階層）とファイル名であっても仕様内の長さ以内であれば扱えます。とても助かりました。ちなみにWindowsのファイルシステム（NTFS）はロングパス・ネームに対応しています。
HDDの不調が発覚したため早いうちにクローンコピー
Windowsシステムを含むシステムディスクが認識しなくなる不具合が出ました。約1年前にも同じ症状が起きて、PCのBIOSでHDDを認識してくれません。1TB 3.5インチHDDを取り外して、制御基板のねじ止めを外して基板の接点をクリーナーで清掃して組み付けると、無事に認識してシステムが起動しました。しかしこれで二度目の認識不良が発生したわけです。
このまま使用し続けると、HDDのデータにアクセスすることが不可能に陥った場合、保存しているデータが全て取り出せなくなる可能性が高いので（復元屋さんに頼むとウン十万円コースでしょう）制御基板の接点清掃で回復した今のうちに新たなHDDにコピーすることにしました。今回がラストチャンスかも知れませんからね。
新品の1TB 3.5インチHDDを新品で購入し、コピーツールで丸ごと移行させることに成功しました。無事にWindowsが起動してくれました。
そこで、この機会にデータファイルのバックアップを取ることにして、更に別のHDDを増設して世代バックアップを取ることにしました。しかしバックアップの段階で丸ごと移行がうまくできていないことが発覚しました。
ロングパスネーム問題でファイルがコピー出来ない
いわゆるロングパスネーム問題で、階層が深いロングネームファイルが不完全になっていて、バックアップに失敗してCRCエラーを表示してしまいます。実際そのコピーしたHDD側のファイル（Jpeg画像）にアクセスすると一部が破損していて、プレビューもダメ、ファイルを開くこともダメです。ファイルの破損はバックアップ処理を走らせなければ気づかなかったと思います。
Windows環境のコピーツールによる丸ごと移行に失敗したのは初めてなので、ロングパス・ロングネームファイルを疑うのは当然の流れでした。原因として考えられる手掛かりが全く無い訳ではなかったのが救いです。
幸いなことに元のHDDはまだ健全なので最悪の事態ではありません。時間さえ許せば（元HDDが健全な限り）色々試せます。HDDを更新した移行先にファイルをコピーする手段を考える必要があります。
BunBackup 256文字を超えるパス名の対応版
フリーで使用できるバックアップソフトとして有名なBunBackupを調べたところ、通常版の他に、ロングネーム・ロングパスに対応したバージョンがあることを知りました。これを使えば元のHDDからバックアップを取ることは可能っぽいです。
しかし、説明を読んでいて注意事項に目が行って気づきました。バックアップは取れても任意のフォルダにコピー（復元）する手段がありません。Windowsエクスプローラがロングパスネームに対応してないからです。
単純に今回元のHDDから新しいHDDにコピーするだけならロングパス対応のBunBackupでも可能ですが、後は定期的にバックアップを取って、いざという時にバックアップから復元したいのでBunBackupではダメです。復元できないのでは意味がありません。BunBackupのテストは中断しました。
ロングパスネームに対応した「7-Zip」を使う
7-Zipはオープンソースで開発されているアーカイブツール（ソフトウェア）です。圧縮機能も備わっているので、zip形式はもちろん7z形式、TAR、ISOなどの形式にも対応しています。7zは圧縮率が高いのも魅力です。
また、コマンドラインからの実行も可能なので、バックアップ対象とバックアップ先をBATファイルに記しておけば、ワンタッチでバックアップ処理を走らせることができます。
検証してみたところ、7-Zipには「7-zip File Manager」というGUIも含まれているので、バックアップ先から目的のファイルを復元させるのもGUIで行えてコマンド操作が苦手なWindowsユーザーにとっても便利です。コレは7-zipを使わない手はありません。
順序は逆になりますが、仕事の環境は特殊な用途のものなので検証目的では使用できませんし、情報として出せるはずもありませんから、自分のPCで検証用に恐ろしく階層の深いロングパスネームの構成でテストしました。下図の様に「GNU LongName ASCII」と扱われていることが分かります。
7-Zipを使ってTarでアーカイブする
検証の結果、元のHDDから必要な画像ファイルが保存されているフォルダ以下をごっそりとTar形式（無圧縮）で別HDDにアーカイブすることにしました。何年もかけて集められたライブラリ（画像ファイル）は、無圧縮なので200GB弱のサイズになりました。
なぜTar形式を選び7z形式（圧縮）を選ばなかったのか？
理由はちゃんとあります。実際に検証してみて判明したのですが、7zに圧縮する場合はCPU負荷が100%近くになり、とても長い時間を要すると分かったからです。Tarなら圧縮せずに1つのファイルに纏めるので1時間もかかりません。
Tar形式はUNIX界隈では標準的で、多くのファイルを1つのTarファイル（Tar Ballなどと呼ぶ）にまとめてしまう整理方法です。もちろんバックアップにも使えます。無圧縮でファイルを固めるということはWindowsしか使ったことの無い人には馴染みのないアーカイバの使い方かも知れませんが、UNIX系に触れたことのある人にとってはアーカイバで複数ファイルを1つに固めるのは常套手段です。
コマンドラインから実行する7-zip（7z.exe）は、aオプション（add）でTarファイルとしてアーカイブにまとめてくれますが、その際にファイルのCRCチェックも実行してくれており、破損ファイルがあった場合には処理が止まることも分かりました。CRCチェックに引っかからず最後まで処理が完了したらTarファイルは完全な状態だと考えてよさそうです。つまりTar ボールにまとめる段階でファイルの健全性診断にも使えます。
このTarファイルを新HDDで起動したPCにUSB-SSDで接続し、まずはGUIの「7-zip File Manager」でごっそりと復元してみました。特にエラーもなくコピーが成功したので、CRCエラーとなっているファイルも上書きされていると考えました。（後にこの考えは間違いだったと判明しました）
しかし、新HDD側に復元したファイルの健全性を確認する目的で、7-zip（7z.exe）でコマンド実行してバックアップHDDにでアーカイブすると、CRCエラーで中断されてしまいます。どうやらロングパスネームに対応した7-Zipと言えども、TarファイルからGUI版「7-zip File Manager」で復元した場合は完全ではなく、CRCエラーを発生させたまま復元されてしまう様です。
※7-Zip単体で処理すれば問題を回避できるかもしれません（後述）。
そこで比較のために、7-zip（7z.exe）でコマンド実行して作成したTarファイルから、7-zip（7z.exe）でコマンド実行してファイルをごっそりと新HDDに復元させました。そして再び7-zip（7z.exe）でコマンド実行して、Tarファイルから全てを復元（xオプション）指定させました。
なぜ何度も行うかと言うと、ファイルが問題なく復元できたか検証するためです。再び7-zip（7z.exe）でコマンド実行してTarファイルにまとめます。今度はCRCエラーの表示が無く最後まで完了しました。つまりTarファイルの作成も復元も成功しているということです。
推測ですが、「7-zip File Manager」からのGUIによるドラッグ＆ドロップによるコピー（復元）は、Windowsエクスプローラ（OS標準）の機能も使っているのではないかと考えます。そのためロングパスネームに非対応のWindowsエクスプローラの仕様に制限されて、不完全なファイル復元になったのではないでしょうか？
結論：完全なバックアップ＆復元は7z.exe（コマンド）で行うべき
今回の試行錯誤によって、ロングパスネームのフォルダとファイルを扱う場合は、全てを7z.exeに任せてコマンド実行でアーカイブ作成、及びアーカイブからの復元を大前提とした方が確実だと分かりました。深い階層の長いファイル名で膨大な数のJPEG画像を復元しても問題は起きませんでした。
7-zip File Managerでも可能かもしれない（未検証）
これは後から気づいたので実際に遭遇した環境では未検証なのですが、7-Zip File Managerから、アーカイブの一番上のフォルダを選んだ状態で、「展開」ボタンをクリックして展開先を7-zipに指定してやる方法があります。この方法なら、Windowsエクスプローラーに渡さないのでうまくできたかも知れません。全てを7-Zip File Managerにで完結させる訳です。
復元時にCRCエラーを誘発させてしまったのは、7-Zip File Managerの仕様が分かってない状態で操作したのが原因じゃないかと考えています。
思い返してみると、7-Zip File Managerからごっそりと復元させて失敗した時は、展開先をWindowsエクスプローラで開いて、「7-Zip File Manager」から「Windows Explorer」にドラッグ＆ドロップしてしまいました。
この操作をした場合のソフトウェアの動作を推測すると、7-Zip File ManagerからWindowsエクスプローラに橋渡しする感じでWindowsエクスプローラが介入するため、ロングパスネームのサポートが実現しなかったのではないかと思うのです。
※しつこい様ですがWindowsエクスプローラはロングパスネームに非対応です。
ただ、不可解なのはCRCエラーが判明したファイルを7-Zip File Managerから個別に上書きで1つずつ復元すると、そのファイルについてはCRCエラーが解消したので、ドラッグ＆ドロップの操作ではダメだとも言い切れません。
既に手元に実環境が無いので試すことができませんが、ロングパスネームに該当するファイルを確実に扱う場合は、7-Zip単体で済ませることが重要になると思えます。同じ課題を突き付けられている方は、Windows Explorerを介入させず、7-Zip単体で完結する方法を試してみてください。
最後に
WindowsユーザーならGUI操作に慣れているので「展開」ボタンをクリックして展開先を指定して7-Zipに任せる方法を取ると思います。それでもうまくできない場合は、7z.exeをコマンドラインで実行するしか手は無いでしょう。それで私は課題をクリアできましたので7z.exeコマンドなら確実だと言えます。
今回のトラブル対応で痛感したのは、やはりWindowsというOSは、まだまだ不完全な部分が多く、ツギハギだらけなんだなと思います。余計な機能を追加実装するのには一生懸命なのに、肝心なところがほったらかしというか・・
Windows11の新しいバージョンでは、Windowsエクスプローラに「7z形式の圧縮/解凍」が機能として追加実装されますが、Windowsエクスプローラが出来が悪いのに、表面的な機能を増やすのは順序が違うと思います。Windowsエクスプローラは、Windows11になってもいまだにパスワード付きZipファイルを作れませんからね。
マイクロソフト社は、中途半端な機能をOS（エクスプローラもOSと考えます）に組み込むよりも、もっと重要な基礎部分を改良して欲しいと願います。
しかし、その間にLinux陣営が完成度の高いOSを作り上げてシェアを奪ってほしいとも願っています。個人的には現在のマイクロソフトのやり方には不満を感じており同社には期待していませんから、その隙きにLinux陣営に頑張ってシェアを奪って欲しいと期待しています。実際、自宅ではLinuxデスクトップ環境をメインで使用しています。Windowsでなくても良くね？という思いは益々強くなります。たまに使おうとするとWindows Updateが動き出して一時間はザラに時間を奪われますし。
コメント