Top  上へ  目次


 Ver.11.5ぐらいの話(ディレクトリの深遠に潜むもの)


 ぶっちゃけた話をすると、11.4の続きだったりします。
 要するに、フルパスでMAX_PATH(260文字)を超える長さのフォルダーの取り扱いの強化です。
 ちなみにAnniversary Update以降のWindows10だと、レジストリやポリシー変更でエクスプローラーの260文字制限が解除できるので、うちも守備範囲を広げる方向です。
※実際に設定を変更すると、MS社のソフトも含めて大惨事になるので設定変更はお奨めしかねます。
※深層を自由にナビゲーションできるレベルの対応であり、深層のファイルを自由に操作できるようにというわけではありません。
 エクスプローラーや外部ソフトなどで閲覧やリネーム/削除などが不可であったり、制限がありすぎるので完全対応するには時期尚早と考えています。

 いわゆる深層のフォルダーですが、最近のエクスプローラーで深いフォルダーを表示しようとすると、このように「ショートファイル名」表記が混ざる場合があります。
 うろ覚えですが、以前はこんなショートファイル名にならなかった気が・・・わりと最近のWindows updateの適用で変わったんじゃないかと思いますが、自信がありません。
 c:\a\a\a\a・・(3万文字省略)・・\a、のようにショートファイル名にしてもはみ出すものはどうすんだろう?と思いますが、私が心配するような話ではないので深追いしないでおきます。

Windows7


Windows10



 通常の状態で深い階層のexeをエクスプローラーから起動すると、Windows10は無反応ですし、Windows7は的外れなメッセージが表示されます。
 ちなみに、これローカルのnotepad.exeをコピーして実行した画面です。

 このように、エクスプローラーの対処もグダグダなのが現状と言えるでしょう。
 多分、そのうち動きが変わるんでしょうね・・・

※補足(2019/7/7現在)
 Window 7は、IShellFolder::ParseDisplayName()がMAX_PATHを超える場合はショートファイル名、ショートファイル名で表現できない場合はエラーを返す。
 ショートファイル名であれば、エクスプローラーから関連付けで開ける、exeはエラーになる。
 Windows 10は、同様にショートファイル名を生成するが、ショートファイル名で表現できない場合はDOSデバイスの修飾を付けて返す。(例:\\?\c:\a\a\a...)
 ショートファイル名であれば、エクスプローラーから関連付け起動はエラー、exeも起動は無反応となる。



 さて、そもそもAs/Rでは、ショートファイル名を考慮してません。
 そのため、Windows APIがショートファイル名を返してくるように仕様が変わったことで、いろんな不都合が発生するようになっています。
 今回は、そのあたりを広範囲に見直しすることになります。

 これ、何が問題かというとショートファイル名とロングファイル名が混ざることがありえます。
 「ショート表記のパス+省略なしのファイル名」という構成もありなんです。
 ところが更新用のインデックスはロングフィル名のフルパスで作っているので、一致していると認識できなくなります。

 複雑なところで、監視ディレクトリ名がショートファイル名になることで更新の通知は拾えてるのですが、実体との紐付けの整合が取れなくなって更新が検知できなくなっています。
 駄目な現象の組み合わせで、もっと駄目になっているという、踏んだり蹴ったりな状況です。
 特に長いパスの一部だけショートファイル名になるとか、部分的に混ざると最悪です。
 ですからショートファイル名である場合、「全て」ロングファイル名に置き換えて情報を補完して管理する必要があります。

 ロングファイル名を作るにはネットワークパスか否か、仮想フォルダか否か、ファイルが存在するか否か、など条件の分岐と生成手順が多いです。
 ざっくりとした試算ですが、一覧性能や、更新性能が10〜20%くらい落ちるかなぁ・・・最近だと小数点以下2〜3桁の0.01%の性能向上とか、メモリ転送回数を1回減らしたとか地道すぎる積み重ねが大損害です。
 まぁ、100万ファイルの列挙が2,400ミリ秒から2,700ミリ秒になったところで、相変わらず認識できる速度差じゃないのですが・・・何となく腑に落ちませぬ。


 あとショートファイル名を生成する際に「はみ出す部分を切り捨てで生成するタイプ」とか(Novellなど)・・・もう良いよね・・・検証環境もないしサポート対象外にせざるをえない気がします。
 というわけで、この手のネタは考慮すべき点が幅広く、対処の影響範囲が広いので、かなり長期間の地道な取り組みが必要になると思います。
 順次対応していくにしても、バグ出しにしても、気長にお付き合いいただければと思います。

 強化ネタとしては、外部コマンドのRename.exeの「異常な名称のリネームを許可」モードも強化されることになります。
 あー、この画面の拡張子分割で行ってるファイルかフォルダーかの判定も、長パス対応してませんね・・・メモメモ。
 できれば、こういった長パスファイルの削除機能とかも作れれば良いんですけど、だいぶ難しいことになってますし。んー。



 さて、このディレクトリの深層の世界がヤバイということの一端を紹介しましょう。
 フルパスで266文字のファイル名を渡した結果です。

 もはや成熟しきったカテゴリだと思いますが、私が常用するテキストエディタの対応状況を調べてみたところMS社の製品もNGがありました。
 少なくとも、落ちるのはまずかなぁと思いました。
エディタ動作
メモ帳正常
VS Code正常
MS-Word 2013コマンドライン無視するが関連付け起動は可、保存は不可
サクラエディタ Unicode Ver.2.2.0.1コマンドライン指定では落ちた、D&Dなどなら開ける/保存可能
秀丸エディタ x64 Ver.8.88起動するしタブが作られるが中身は空っぽで読み込めない、その状態で保存するとエラーメッセージ
Mery x64 Ver.2.8.0コマンドライン指定は無視してMeryだけ起動、D&Dなどなら開ける/保存可能
Bz Editor Ver.1.6.0コマンドライン指定ではアプリが起動しない、D&Dなどなら開ける/保存可能
OEdit Ver.8.0.0.4コマンドラインでは落ちる、D&Dなどでもエラー表示
Cassava Ver.2.0.6コマンドラインではエラーメッセージ、D&Dなどなら開ける/保存可能
Txv.exeコマンドラインではエラーメッセージ、D&Dなどなら開ける
 エディタじゃないですが、うちのTxvもおまけで付けておきました。
 コマンドラインを処理するライブラリからして古いものは似たような対処になってるでしょう。
 要するに、対応してるアプリの選択肢が極めて少ないってことが言いたいわけで、この辺りを脆弱性の攻撃のネタにされたら大変めんどくさいことになります。


 おそらく統合アーカイバプロジェクトのDLLとか、ライブラリからしてNGな時代に生まれたソフトもありますので、あまり気にし過ぎない方向で考えていますが、可能な限り救いたいと考えてます。
 多分、Ver.11.6も継続しそうですね・・・すでに修正点が100か所を超えてますし。数が多くてしんどいorz