フォルダ階層奥深くにあるファイルをコピーできない~Windowsを使っていると遭遇するLong Path問題の回避に7-zip

プログラミング PC
プログラミング

私の仕事では、色々な人が使っているPCの維持管理もあるので、たまに想定外の使い方をしている人がいて、維持管理に苦労する場面があります。

ファイルの整理にフォルダ階層が何層にもなっていて、しかもフォルダ名、ファイル名が異様に長い状態で使用している人のPCがトラブルを起こしたため、リカバリーする必要に迫られました。とても特殊な仕事をしている人なのでこの使い方を否定することもできません。

IT関係者の視点で言えば、現在のWindowsで使用されているファイルシステムはNTFS(New Technology File System)と呼ばれる方式で、Windows NTから採用された当時は画期的なファイルシステムだったと記憶しています。このNTFSの問題というよりは、Windowsを構成する各種のプログラム(エクスプローラとか)が置き去りになっている為に、NTFSでサポートしているロングパス、ロングネームのファイル名を扱うと思わぬトラブルに遭遇することが稀にあります。

今回それに相当する課題が降ってきてしまいました。

PCのHDDがトラブルを起こしたため、新しいHDDにコピーしたいのですが、ロングパスの問題でコピーができない状態です。

対処方法として結論から先に記すと、7-Zipを使ってこの課題を克服することが出来ました。7-Zipはロングパス・ロングネームに対応しているため、とても長いPATH(階層)とファイル名であっても仕様内の長さ以内であれば扱えます。とても助かりました。

HDDの不調が発覚したため早いうちにクローンコピー

Windowsシステムを含むシステムディスクが認識しなくなる不具合が出ました。約1年前にも同じ症状が起きて、PCのBIOSで認識してくれません。1TB 3.5インチHDDを取り外して、制御基板のねじ止めを外して基板の接点をクリーナーで清掃して組み付けると、無事に認識してシステムが起動しました。しかしこれで二度目の認識不良が発生しました。

このまま使用し続けると、HDDのデータにアクセスすることが不可能に陥った場合、保存しているデータが全て取り出せなくなる可能性が高いので(復元屋さんに頼むとウン十万円コースでしょう)接点清掃で回復した今のうちに新たなHDDにコピーすることにしました。

新品の1TB 3.5インチHDDを新品で購入し、丸ごと移行させることに成功しました。また、この機会にバックアップを取ることにして、更に別のHDDを増設して世代バックアップを取ることにしました。しかしバックアップの段階で丸ごと移行がうまくできていないことが発覚しました。

いわゆるロングパスネーム問題で、階層が深いロングネームファイルが不完全になっていて、バックアップに失敗してCRCエラーを表示してしまいます。実際そのファイル(Jpeg画像)にアクセスすると破損していて、プレビューもダメ、ファイルを開くこともダメです。バックアップを走らせなければ気づかなかったと思います。

丸ごと移行に失敗したのは初めてなのでロングパス・ロングネームファイルを疑うのは当然の流れでした。原因として考えられる手掛かりが全く無い訳ではなかったのが救いです。

幸いなことに元のHDDはまだ健全なので最悪の事態ではありません。時間さえ許せば色々試せます。HDDを更新した移行先にファイルをコピーする手段を考える必要があります。

BunBackup 256文字を超えるパス名の対応版

フリーで使用できるバックアップソフトとして有名なBunBackupを調べたところ、通常版の他に、ロングネーム・ロングパスに対応したバージョンがあることを知りました。これを使えば元のHDDからバックアップを取ることは可能っぽいです。

しかし、説明を読んでいて注意事項に目が行って気づきました。バックアップは取れても任意のフォルダにコピーする手段がありません。Windowsエクスプローラがロングパスネームに対応してないからです。

単純に今回、元のHDDから新しいHDDにコピーするだけではだめで、今後は定期的にバックアップを取って、いざという時にバックアップから復元したいのです。BunBackupのテストは中断しました。

ロングパスネームに対応した「7-Zip」を使う

7-Zipはオープンソースで開発されているアーカイブツール(ソフトウェア)です。圧縮機能も備わっているので、zip形式はもちろん7z形式、TAR、ISOなどの形式にも対応しています。7zは圧縮率が高いのも魅力です。

また、コマンドラインからの実行も可能なので、バックアップ対象とバックアップ先をBATファイルに記しておけば、ワンタッチでバックアップ処理を走らせることができます。

検証してみたところ、7-Zipには「7-zip File Manager」というGUIも含まれているので、バックアップ先から目的のファイルを復元させるのもGUIで行えてコマンド操作が苦手なWindowsユーザーにとっても便利です。

順序は逆になりますが、仕事の環境は特殊な用途のものなので検証目的では使用できませんし、情報として出せるはずもありませんから、自分の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などと呼ぶ)にまとめてしまう整理方法です。もちろんバックアップにも使えます。

コマンドラインから実行する7-zip(7z.exe)は、aオプション(add)でTarファイルとしてアーカイブにまとめてくれますが、その際にファイルのCRCチェックも実行してくれており、破損ファイルがあった場合には処理が止まることも分かりました。最後まで処理が完了したら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に任せてコマンド実行でアーカイブ作成、及びアーカイブからの復元を大前提とした方が確実だと分かりました。深い階層の長いファイル名でも問題は起きませんでした。

7-zip File Managerでも可能かもしれない(未検証)

これは後から気づいたので実際に遭遇した環境では未検証なのですが、7-Zip File Managerから、アーカイブの一番上のフォルダを選んだ状態で、「展開」ボタンをクリックして展開先を7-zipに指定してやる方法なら、うまくできたかも知れません。

復元時にCRCエラーを誘発させてしまったのは、7-Zip File Managerの仕様が分かってない状態で操作したのが原因じゃないかと考えています。

思い返してみると、7-Zip File Managerからごっそりと復元させて失敗した時は、展開先をWindowsエクスプローラで開いてそこにドラッグ&ドロップしてしまいました。ソフトウェアの動作を推測すると、7-Zip File ManagerからWindowsエクスプローラにバトンタッチする感じでWindowsエクスプローラが介入すると推測されるため、完全なロングパスネームをサポートが実現しなかったのではないかと思うのです。

※しつこい様ですがWindowsエクスプローラはロングパスネームに非対応です。

ただ、不可解なのはCRCエラーが判明したファイルを7-Zip File Managerから個別に上書きで復元すると、そのファイルについてはCRCエラーが解消したので、ドラッグ&ドロップの操作ではダメだとも言い切れません。

既に手元に実環境が無いので試すことができませんが、ロングパスネームに該当するファイルを扱う場合は、7-Zip単体で済ませることが重要になると思えます。同じ課題を突き付けられている方は、Windowsエクスプローラを介入させず、7-Zip単体で完結する方法を試してみてください。

最後に

「展開」ボタンをクリックして展開先を指定して7-Zipに任せてもうまくできない場合は、7z.exeをコマンドラインで実行するしか手は無いでしょう。それで私は課題をクリアできましたので確実だと言えます。

やはりWindowsというOSは、まだまだ不完全な部分が多く、ツギハギだらけなんだなと思います。Windows11の新しいバージョンでは、Windowsエクスプローラに「7z形式の圧縮/解凍」が機能として追加実装されますが、Windowsエクスプローラが出来が悪いのに、表面的な機能を増やすのは順序が違うと思います。

中途半端な機能をOS(エクスプローラもOSと考えます)に組み込むよりも、もっと重要な基礎部分を改良して欲しいと願います。しかし、その間にリナックス陣営が完成度の高いOSを作り上げてシェアを奪ってほしいとも願っています。個人的には現在のマイクロソフトのやり方には不満を感じており同社には期待していません。

コメント

タイトルとURLをコピーしました