一括表示

発症するのはファイル名ヒストリーです。
やはり、過去数年にわたって、時々症状が発生しています。
ただ、#2229で書いたコマンドラインヒストリーよりは頻度が高いです。
月に数回はお目にかかっています。

症状に気がついているのはポケ３です。DOS3.1。
konnoさんの作られた省電力バージョンでも、それ以前のバージョンでも同じ
く症状が出ています。
VZ.DEF の中で history2 をインクルードしています。また、hf1024になって
います。autoexec.bat でＶｚを常駐させていますが、この際、以前の履歴を
読み込むために、A:\vz\vz.com -z @@ と指定しています。これで起動直後に
蓄積される履歴は、現在は58です。現在は、というのは、editfileのタイム
スタンプは06-10-22だからです。もちろん、症状はそれ以前から出ています。
起動直後のカレントディレクトリは、autoexec.batでB:\に設定しています。
また、関係あるとは思えませんが、autoexec.bat内でＶｚを常駐させる前に
rswapを常駐させています。

ポケ３の場合、なにかあったらサクッとメモを取りたいのです。
そのため、私はメモ用のファイルには短いファイル名をつけているのですが、
伝統的にというか、「N」一文字、拡張子なしのファイルをよく使います。こ
れは、ファイラーから新規ファイルをオープンする場合にこのファイル名が
一番速かったので、その名残りでしょう。このファイルはよっぽどなにかが
ない限り、常にB:\に存在しています。以下、このファイルのことをメモファ
イルと表現します。

さて、history.defで見ると、このeditfileを読み込んで立ち上がった直後の
ファイル名ヒストリーは以下のようになっています。

0 N
1 A:\VZ\VZ.DEF ->4C7D
（中略）
5 A:\L\2.LO ->0
6 .LOG ->1C5CD
（中略）
9 N ->20
A B:\N ->E
（中略）
D B:\N ->EB
（中略）
I B:\M\N ->1
J DEF ->1E65
K \N ->A
L ->10F
（以下略）

関係ありそうなところだけ抜き出しています。
なんか、この段階で既におかしいのかもしれません。

autoexec.bat終了直後、コマンドラインから、ポケ３用の省電力ツールを常
駐させます。次に、テキスト文書閲覧でmiel、または過去ログ閲覧でnifpを
起動します。それらのアプリからチャイルドプロセスに抜けて、コマンドラ
インから[ESC]でファイル名窓を出し、上矢印一発でメモファイルをオープン
してメモを記入したり、コマンドラインから\[RET]でメモファイルではない
ファイルをオープンして閲覧・参照・編集したり、メモファイルオープン中
に別ファイルを参照したり、ということをします。この際、少なくとも意識
してはカレントドライブやカレントディレクトリを移動してしまうことはな
いのですが、無意識のうちに行ってしまい、それが以下の症状に影響してく
る可能性はあるかもしれません。また、メモファイルだけを編集もしくは閲
覧した場合は症状が出ることは少ないようです。もしかしたら、症状が出た
ことはないかもしれません。

さて、メモファイルを編集したりしなかったりするわけですが、カーソルを
動かして終了することが多いので、ヒストリーの一番上は、メモファイルに
カーソル位置情報がくっついた形で保存されていることが期待されているわ
けです。そして、チャイルドプロセスを一旦exitで抜けてアプリに戻り、再
びチャイルドプロセスに降りるか、あるいはアプリを終了させる場合もあり
ますが、とにかくコマンドラインにやってきます。そして、メモファイルを
編集しようと、[ESC]でファイル名窓を出し、上矢印を押しても、なぜかメモ
ファイル名が出てこない。一発目に出てくるのは別ファイル名。ん〜、既に
忘れているけど、クローズ順はそうだったっけか、と思いながらさらにもう
何回か上矢印を押しても一向にメモファイル名が出てこない。何回も押して
やっと出てきたと思ったら、上記ヒストリーでいうところの１０番目という
か、「B:\N ->E」なんですよ。つまり、ドライブ名なしのメモファイル名と
いうのが消えてしまうのです。

実は今日、３０分ぐらい空時間があったので、なんとか再現させようと努力
したのですが、ついに１回も再現させる事ができませんでした。ま、世の中
そんなものなのかもしれませんが。でも、ある程度の頻度で起きているだけ
に余計悔しい。


ということで、お知恵をお貸しいただければと思います。
 

思い出したことがあって追記。

最初にチャイルドプロセスに降りて、いろいろと閲覧したり編集したりする
わけですが、この時、巨大なファイルを閲覧対象としたときに、この事象が
起きる頻度が高いような気がしています。巨大といっても数百ＫＢですが。

EM64を指定していますが、Ｖｚ常駐時の空きＥＭＳは６２ページしかないの
で、「最大６２ページ使用します」のメッセージが出ています。VZTEMP.$$$
が置かれるのはB:\ですが、ここの空き容量は最大で数百ＫＢです。rswapの
swapファイルもこのディレクトリに置かれるので、チャイルドプロセス時に
は空き容量が数十ＫＢ以下になっていることもあります。

メモファイル（B:\N）は、最大でもせいぜい数ＫＢです。
その他、関連しそうなファイルとしては、英単語と和訳の羅列してあるテキ
ストファイルのA:\ENG.DICのサイズが約７００ＫＢ弱。このファイルには、
リードオンリー属性がついています。
あとは、B:\の数百ＫＢのファイルを参照することがあるかな。ファイル名は
そのたびごとに異なるので関係ないでしょう。これは、編集することは絶対
にありません。なぜなら、親プロセスのmielやnifpで参照中のファイルだか
らです。うっかりするとテンポラリファイルエラーが出ることもありますが、
その時には即座にクローズしてから開き直し、^QVで閲覧専用としています。
もちろん、チャイルドプロセス中に、A:\VZ\VZ.DEFをはじめとするその他の
ディレクトリにあるいろんなファイルを閲覧・編集することもありますが。

実は、昨日の実験では、これらの大きなファイルの参照を行うような形のも
のは行ったのですが、その他、小さいファイルを取り混ぜて行うという部分
がすっかり抜けていました。なので再現できなかったのかもしれません。
 

今日、再発しました。再現できる手順も、少しわかりました。
どうも、テンポラリファイルエラーがからんでいるようです。

まず、環境面では、今までの記述で特に修正が必要な部分はありません。
今回のメインキャストはB:\2.LOG  208386bytes
それと、　　　　　　　B:\1.LO   181922bytes　←拡張子に注意
B:\Nは、ヒストリーからは消えましたが、直接にはファイル操作はしていま
せん。あと、追加事項として、カレントドライブであるB:\の起動時の空き容
量は446464bytes。

事象再現時の手順は以下の通り。ちょっと長くなりますが箇条書きにします。

( 1)電源ＯＮ　→　autoexec.bat終了でコマンドライン
( 2)省電力ソフト「PDC」常駐
( 3)N[RET]
　↑これはVZ.DEF内でエイリアスで「Nifp *.log」と展開される
　　ここで、上記のログファイルの拡張子が微妙に設定されているところが
　　関係してくる
( 4)NIFPからチャイルドプロセスに降りる
　この時、rswapの作ったスワップファイルのサイズは 261680bytes
　B:\の空き容量は 184320bytes
( 5)ファイラーから2.LOGを選択してオープン
( 6)2.LOG内に存在しない文字列を検索文字列を設定して\[DOWN]
( 7)「見つかりません」が一瞬表示された後「テンポラリファイルエラー」
( 8)[ESC]Cでただちにファイルクローズ
( 9)再びファイラーで2.LOGを選択してオープン
(10)オープン直後に^QVでビューモード
(11)\[DOWN]で「見つかりません」表示
(12)[ESC]Cでクローズ後、今度はファイラーで1.LOGをオープン
(13)オープン直後、検索文字列の再設定などはせずに、そのまま\[DOWN]
(14)今度は検索文字列あり、見つかった個所でそのまま[ESC]Cでクローズ
(15)ファイラーからHでコマンドプロンプトに抜ける
(16)EXITでチャイルドプロセス終了
(17)再びチャイルドプロセスに降りる
(18)ここでhistory.defでヒストリーが消えてしまっている事を確認

設定している検索文字列ですが、2.LOGには存在していないけど1.LOには存在
しているという複数の文字列で同じ状況になることを確認しています。
一方、これのバリエーションというか、以下の手順で症状が発生しないこと
も確認しました。

〜(5)までは同じ動作
( 5)ファイラーから2.LOGを選択してオープン
( 6')2.LOG内に存在する文字列を検索文字列を設定して\[DOWN]
( 7')「テンポラリファイルエラー」にならない部分で文字列発見
( 8')見つかった個所で[ESC]Cでただちにファイルクローズ
( 9')[ESC]Cでクローズ後、今度はファイラーで1.LOGをオープン
(10')オープン直後、文字列検索等はせずにカーソル移動のみ
(11')ファイル先頭ではないところにカーソルを置いて[ESC]Cでクローズ
(12')ファイラーからHでコマンドプロンプトに抜ける
(13')EXITでチャイルドプロセス終了
(14')再びチャイルドプロセスに降りる
(15')ここでhistory.defでヒストリーが消えていない事を確認

この２つの手順で一番大きく異なるのがテンポラリファイルエラーの有無。
近いうちに、もっと少ない手順で発症するか確認します。

さて、上記手順の(18)の段階で、history.defでみるとどのようになっている
かということを、以下に記します。

0 1.LOG ->29B4A
1 B:\2.LOG ->0
2 F ->4C7D
3 A:\L\A ->A6
（中略）
A N ->20
（後略）

今回、ドライブ名なしのメモファイルのヒストリーは全部消えてしまったわ
けではありません。ヒストリーのトップのものだけが消えてしまった形です。
ところが、それだけではありません。ヒストリーの３番目に、「F」なる妖し
いファイルの履歴があります。でも、私、こんな名前のファイルを操作した
ことはありません。だけど、前回、#2246に記載したＶｚ起動時のヒストリー
と比較すると正体がわかります。これ、前回記載したヒストリーでいうとこ
ろの２番目、VZ.DEFの履歴の、前半部分がごっそりと削られてしまっている
ものなのですね。

どうも、テンポラリファイルエラーが起きると、ファイル名ヒストリの一部
が破壊されてしまうようです。果たしてこれは、本当にテンポラリファイル
エラーが絡んでいるのか、それとも他の要因なのか、さらに追試を行います。
また、ポケ３バージョンに特化したものなのか、他のバージョンやオリジナ
ルでも発生するものなのか、メインマシンなどでも実験してみたいと思いま
す。ただ、最近は外部記憶装置などが潤沢にあるので、なかなかテンポラリ
ファイルエラーを出せる環境が見つからない、というのもあったりするんで
すよねぇ。
 

> 　おお，ついに手順が特定できましたか。

ところが、さらに調査を進めたところ、とんでもないことがわかりました。

> 　ふうむ。テンポラリファイルエラーが起こらないようにしてやれば解決ということになるかもしれませんね。

解決しません。なんと、テンポラリファイルエラーは関係なかったのです。

> 　ちょっとだけバイト数が合わないように感じるのは気のせいかしら。

えと、ごめんなさい、バイト数が合わないというのは、どことどこを比較し
ておっしゃっているのかよくわかりません。私が何か誤記をしたかな？



さて、手順をずばずばと短くして行った結果、再現させる最小の手順という
のがわかりました。それはなんと

(1)任意のファイルをオープン
(2)^QV

なんと、これだけで、ファイル名ヒストリーが壊れるのです。
事象は、ポケ３オリジナル版でもkonno省電力版でも同様です。
ひどい時には、ポケ３を起動してすぐ、ちょっとどういう操作を行ったかは
覚えていませんが、ほんの２〜３回、ファイルのオープン、^QV、クローズを
行って、最後、リードオンリー属性が付いているA:\ENG.DICをオープンして
（当然、ビューモードでオープンされています）^QVをしたら、なんとファイ
ル名ヒストリーがすべて消失してしまいました。
また、比較的フルパスが長いファイル、A:\LSIC\SRC\BIN\MAKE\MKDEP.DOCを
オープンして^QVしたら、９番目という数え方でいいのかな、#2249で示した
「9 N ->20」が「7 ->20」まで上がってきていました。０番目にこのファイ
ル自身のヒストリーが追加されているわけですから、上の方３つ分が丸まる
消失してしまっている勘定になるわけです。

試した範囲では、他のバージョンでは今のところ症状をおこす事に成功して
いません。多分、ポケ３版特有のバグといって良いと思います。もしかした
ら私のVZ.DEFが悪さをしている可能性もあるかもしれませんが、ちょっと考
えにくい。

ということで、めざらさんに教えていただきたいことは以下の通り。

・ファイル名ヒストリーバッファの構造
　カーソル位置情報も文字列でもっているのでしょうか。
　それとも、ロング整数？
　なんか、ＦＡＱのページに既にありそうな気がするのですが、
　そうであればＵＲＬだけ教えて下さい。
・VZ.DEFなどの設定がファイル名ヒストリーに影響を与える可能性
　私のVZ.DEFはＷＥＢで公開済みだけど、あら捜しはしないで下さい(^^;
・^QVのルーチンはどのソースファイルにあるか
　私はこれが一番怪しいと思っているんですよ。
　多分、削除するバイト数の計算を間違っているのではないかと。
　もし、どのソースにあるかわかれば、オリジナルとポケ３版を比較する
　ことにより、バグ修正することもできるのではないかと。
　もちろん、修正バージョンのリリースはkonnoさんにお願いしますが(^^;

なにとぞ、ご助言をお願いします。
 

> ^QVをしたら、なんとファイル名ヒストリーがすべて消失してしまいました。

　まず，^QV であるキーにアサインされたコマンド／マクロが何であるか，…
というところから始めなくてはなりません。

　製品版のサンプル VZ.def では，^QV にアサインされているのはマクロで，
「これからオープンするファイルをすべてビューモードでオープンするように
するモードに移行する」マクロです。

　ところが，としきさんのコメントを読んでいると， どうやら ^QV にアサイ
ンされているマクロは，どうやら即効ビューモード（現在オープンされている
ファイルをビューモードで開き直す）であろうと想像できます。代表的なのは
上村さんの古典があります。

　さて，この上村さんのマクロ，としきさんの感覚で言うなら「バグ」が存在
します。 いや，実際には ^QV のビューモードマクロにバグがあるのではなく
て，コールされている [ESC]U/@U 「編集のやり直し」にバグがあるのです。

　上村さんのオリジナルを示します。
7  [ESC]U @U "U 編集のやり直し"
        ?. #]
        (mr==1)?{ &a(37) (r<1)?. }
        &s ky[, ht[, we[,
        #M &Sp(pf,"%s ->%lx",wa+$92,wa..63,wa..64)      ;★
        mr-, #L #e #m
        we], ht], ky],
        &d #]

　★の行に注目してください。&Sp() で pf に上書きしています。
　つまり，^QV だけでなく，[ESC]U で pf ヒストリは破壊されます。

　これはかなり前に気付いて次のようにしています。
（会議室などで上村さんに報告したかどうかは忘れてしまいました。）
;7 [ESC]U "Undo Edit"   ;Ikuo   view mode の直後に置く
;       ?. #] (mr==1)?{ &a(37) (r<1)?. }
;       &s ky[, ht[, we[, #M
;       &Sp(pr,"%s ->%lx",wa+$92,wa..63,wa..64) ;prを介してpfを破壊しない H_ear
;       &Sh(pf,pr)
;       mr-, #L #e #m we], ht], ky], &d #]

　その後，m.gann 師から改訂意見が付いて次のようになり，
;7 [ESC]U "Undo Edit"   ;m.gann+ikuo
;       ?. &a(37) (wn&&r>0)??.
;       mr3, ht[, we[, ly[, ln[, &s #L #P #m
;       &#J(r]) ky], we], ht], &d

　最終的に，現在は次のものを使用しています。
7 [ESC]U "Undo Edit"    ;ikuo+m.gann    ;view mode の直後に置く
        ?. (wn)??.                      ;consoleでは何もしない
        #] (mr==1)?{ &a(37) (r<1)?. }   ;?. &a(37) (wn&&r>0)??.
        mr-, ht[, we[, ly[, ln[,        ;mr3, == #] mr-,
        &s #L #P #m                     ;#L:マクロ中では入力窓固定
        &#J(r]) ky], we], ht], &d       ;ky代入後&d必要

　やしきに掲載されている VZ.def も確認させていただきました。

　どんぴしゃ，のはず。


　ちらと目に入った次のマクロ「オプションの初期化」も危険ですね。
　vw と zk を保護することをお奨めします。
        r=34&jx, &^ jx|=r,              ; オプション初期化／vw, zk は保護


> ということで、めざらさんに教えていただきたいことは以下の通り。

　これらは必要ですか？
　バッファの構造はわかりますが，カーソル位置情報などは少し複雑ですね。
カーソル行指定とカーソル位置ポインタ指定，末尾指定などがあります。

> 27 ^KO "O オプションの初期化"
>      r=34&jx, &^ jx|=r,              ; オプション初期化／vw, zk は保護

        &d      ;スクリーンの再表示
        #]      ;ステータスラインの再表示

　これを加えた方がよいでしょうね。

ぅぉぉ、これで積年の不具合が解決しそうです。
どうもありがとうございます。

> て，コールされている [ESC]U/@U 「編集のやり直し」にバグがあるのです。

そうだったのですか。
さっそく書き換えます。

ただ、ここで、新たな疑問。
メインマシンでも同じマクロを使っているにも関らず、こちらでは全く症状
が発生しません。これはなぜなんでしょうか。
もしかして、PC-98依存のコードを使っているということなのでしょうか。

> 　やしきに掲載されている VZ.def も確認させていただきました。
> 　どんぴしゃ，のはず。

あはは、やっぱりあら捜しをされてしまいました。
でも、フリーウェアのソース公開と同じようなものですから、こういうもの
はなんでもかんでも公開しておくと便利だと思いました。

> 　ちらと目に入った次のマクロ「オプションの初期化」も危険ですね。

こんなマクロ、使った事もないというか、存在すら忘れていました。
多分、このキーアサインそのものも使ったことがないに違いありません。
もっとも、使っていない機能はたくさんあって、^QOを使いはじめたのだって
やっとここ２年ぐらいのものだったりします。
話を元に戻して、このマクロ、c.mosさんの作られたオリジナルから使われて
いるようなんですが、どう危険なんですか？
オリジナルＶｚでは怪しい挙動を起さないような構造なんでしょうか。
使用頻度から考えて、いっその事、すっぱりとこのマクロを削除してしまっ
てもいいのかもしれません。

> 　これらは必要ですか？
> 　バッファの構造はわかりますが，カーソル位置情報などは少し複雑ですね。
> カーソル行指定とカーソル位置ポインタ指定，末尾指定などがあります。

今、急いで教えていただく必要は全くなくなりました。
ただ、こういう情報は、いずれ必要になる時が来るかもしれません。
ということで、そのうちにサイトに掲載しておいてもらえればありがたいか
な、という程度で。
 

> なにせ、メインマシンのVZ.DEFもＷＥＢ上に公開してあるわけですから。

　でも， 外部マクロとして読み込まれたマクロのキーが ^QV であったという
可能性だってあるわけですからね。

> ん〜、もうちょっと追試してみますが、フルパスの長さがある程度以下とか、

　フルパスの長さが一致していたというのに一票。


　ところで，^KO の拡張版は上村さんのものです。

50 ^KO  "whip"                          ; マクロバッファに鞭をいれる
        (128){ &Zd(mg..4) }             ; 外部マクロ一括削除
        r=34&jx, &^ jx|=r,              ; オプション初期化／vw, zk は保護
        &d &m("Bm:%u bytes free",bm)
        (ks&1)? cm=1,

　あれ？　別にシフト実行ってわけではないですね。今までいつもシフト実行
してました。(^^;

> 私の考えていたのはそういうのではなくて、よくあるポインタの図解のよう
> なもので

　こんな感じでしょうか。ポインタ変数の指すバッファ先頭アドレスの直前に
２バイトのサイズ情報があります。ヒストリーバッファには，必ずこのサイズ
情報があります。

 <-SIZE-> ↓pfの先頭アドレス
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│00│01│Ｃ│：│￥│Ａ│．│Ｔ│Ｘ│Ｔ│00│Ｆ│　│−│＞│４│
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
　　　　　　　↓ヌル（文字列の終端／デリミタ）　　　　↓カーソル位置情報
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│Ｃ│７│Ｄ│00│Ａ│：│￥│Ｌ│￥│Ａ│　│−│＞│Ａ│６│00│
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
　　　　　　　　　　　　　↓　↓連続したヌルがバッファ終端
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┐
│Ｎ│　│−│＞│２│０│00│00│￥│Ａ│　│−│＞│Ａ│６│00│
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
　　　　　　　　　　　　　　　　　→ここから先はゴミ

　カーソル位置情報はそのまま十六進数を表わす文字で入っています。

　オプションの順序性というのは何でしょう。 #Q で EDITFILE に記録された
窓分割・配置情報のことでしょうか。

> 　でも， 外部マクロとして読み込まれたマクロのキーが ^QV であったという
> 可能性だってあるわけですからね。

なるほど、確かに。

> 　フルパスの長さが一致していたというのに一票。

あ〜、これは当たってそうな気がする。
実は、全然コードが理解できていないのですが、フルパスの長さがたまたま
一致していれば、症状は出ないものなのですか？

> 　こんな感じでしょうか。ポインタ変数の指すバッファ先頭アドレスの直前に
> ２バイトのサイズ情報があります。ヒストリーバッファには，必ずこのサイズ
> 情報があります。

そそそそ、これこれ、こういうのが見たかったのですよ。

> 　カーソル位置情報はそのまま十六進数を表わす文字で入っています。

これ、例えば、MR128とかって情報も、この場合は十進数ですが、そのままの
文字列で入っているんですか？

> 　オプションの順序性というのは何でしょう。 #Q で EDITFILE に記録された
> 窓分割・配置情報のことでしょうか。

編集テキストオプションやマーク情報のことです。
実際にオープン窓に直接記入する時にはどんな順序でもよいみたいですから、
あまり順序依存性はないんでしょうね。でも、Ｖｚがヒストリーに記録する
時はある一定の順序で記録されるようですので、なんとなく、その順序でな
くてはならないのかなと思い込んでしまったようです。