ファイルサーバのソースを開いていると、No.36625
hexa lion さん 18/06/08 16:28
 
こんにちは
2〜3年前のスレを引っ張り出さない方が良いかと思い、あえて新規に投稿します。

ファイルサーバ上のファイルを開いている際に
・実際には別の更新は行われていないはずなのに、秀丸が「ファイルが更新されてい
る」と認識
・その影響で、いちいち再読み込みを行うかダイアログが出てしまう
という件でお問合せをさせていただきました。
結局その時は色々調査をして頂いていたのですが
・おそらく再現しない環境が多いらしい(同様の問い合わせはほかに1件しか記憶に
ない)
・担当さんの環境では再現確認が出来ず手を出しにくい
という状態でしたようなので、そのまま放置しておりました。

最近はローカルのソースを編集して、完了したものだけサーバにアップしていたため、
余り気になってはいなかったのですが、本日ファイルサーバで管理しているソースを
直接いじることがあり、問題が再現したのでお問合せいたしました。

最近のバージョンで、秀丸が再読み込みを試みる際に、タイムスタンプ情報を表示し
てくださるように変わっていたので、その状態を報告させていただきます。

例1:とりあえず再現した記録
実際のファイルのタイムスタンプ:2018/06/08 15:38:26.616
秀丸エディタが記憶しているファイルのタイムスタンプ:2018/06/08 15:38:23.462
秀丸エディタがファイルを保存したときのPCの時刻:2018/06/08 15:38:26.616

例2:意図的に再現させた記録
実際のファイルのタイムスタンプ:2018/06/08 16:13:10.964
秀丸エディタが記憶しているファイルのタイムスタンプ:2018/06/08 16:13:00.676
秀丸エディタがファイルを保存したときのPCの時刻:2018/06/08 16:13:00.752

例2は、ローカルの時間で16:13に変わったタイミングで、[Ctrl]+[S]による保存を行
いました。
ファイルサーバの時計は、秒単位で一致している事を確認しています。

例以外にも何度か確認していますが「秀丸エディタが記憶しているファイルのタイム
スタンプ」が、常に一番早い時刻を指します。

[ ]
RE:36625 ファイルサーバのソースを開いてNo.36626
秀丸担当 さん 18/06/08 17:11
 

詳しい情報ありがとうございます。
V8.81でタイムスタンプを表示するようにしたのは、Windwso 10のクライアントとWin
dows 10のサーバーで自分の所で稀に再現するようになって、それで調べることがで
きるかもしれないと思って表示を追加しました。
いま改めて試してみたのですが、今は何度かやっても再現しませんでした。
(というかVersion 1803になったせいか、ネットワークにサーバー名が出てこなくな
ってしまって、IPアドレス直接でしか見れなくなってしまったのですが)

前に再現したときにわかったこととしては、やっぱり本当にタイムスタンプは変わる
ことがあって、変わっているからそういうものということとしか言え無さそうでした。
それを解決するには、以前追加した設定の「許容誤差」を指定するか、さらに「ファ
イルのサイズを時々チェックする」も一緒にONにするといいと思います。

ちなみにこれは確かではないですが、以前Visual Studio 2013や2015で試したとき、
VisualC++は秀丸エディタで更新しても数秒検出できない時間がありました(いまと
なってはそういう記憶です)。そのときはVisual Studioは最初から許容誤差がある
のかと思っていました。
今試してみたら、Visual Studioは許容誤差は無くて、読み込み直すボタンを押した
ら、タイムスタンプが変わってしまい、もう一回同じダイアログが出る動作になって
いました。以前試したときとの違いはなぜかは不明です。
SMB2のキャッシュか何かわからないですが、最近のWindowsでは本来とは違うタイム
スタンプの更新がされることがあるようです。



[ ]
RE:36626 ファイルサーバのソースを開いてNo.36629
秀丸担当 さん 18/06/11 09:10
 

その後再現できるようになり、原因もわかりました。
次のβ版でトラブル対策のオプションを追加するか、何らかの対策をしたいと思いま
す。

条件はV8.33β6以降で、高速バックアップはOFFで、既存のファイルを上書きして保
存した後、こちらの環境では20秒くらいの遅延でタイムスタンプが変わりました。
保存後秀丸エディタを終了しても再現して、メモ帳でも再現するようです。

V8.33β6より前との違いは、保存開始してファイルの終端をまず設定するかどうかで、
V8.33β6より前は保存開始してサイズ0にしてから内容を書き出します。V8.33β6以
降はサイズ0にせず内容を書き出した後に終端を設定します。
書き出している最中にエラーが起きて中断されてしまったとき、情報が失われるのを
防ぐための対策でした。
V8.33β6より前と同じにすると回避できるわけですが、それだと情報が失われるリス
クがまた出てしまうので、トラブル対策のオプションの追加を検討したいと思います。
高速バックアップがONの場合は、既存のファイルをリネームしてから新規に保存する
ので、再現しないです。

メモ帳も同じ書き出しの仕方をしていると思われ、こういう上書きの仕方をすると、
SMB2のキャッシュか何かわからないですが、アプリを終了させた後であっても更新さ
れたりするようです。


[ ]
RE:36629 ファイルサーバのソースを開いてNo.36631
hexa lion さん 18/06/11 11:08
 
調査ありがとうございます。
>V8.33β6より前と同じにすると回避できるわけですが、それだと情報が失われるリ
>スクがまた出てしまうので、トラブル対策のオプションの追加を検討したいと思い
>ます。
SMB経由の書き込みの際の遅延処理っぽいので、明らかに秀丸原因の問題ではない事
は了解しております。
「このファイルはこれ以降チェックしない」をしてしまえば問題はないので、とりあ
えず運用の支障はありませんし、万が一の際に情報が失われてしまう方が問題だと思
うので、明確に「こうすれば良い」という解決策じゃないなら、前向きな対応はしな
くても良いような気がします。

>高速バックアップがONの場合は、既存のファイルをリネームしてから新規に保存す
>るので、再現しないです。
SMB側での排他処理関連の影響の可能性はあるのかと思います。(なので新規保存に
対しては同じ事が起きない?)

何にしても、この様な問題が発生しない環境も多そうですし(何の違い?)、運用で
カバーする手段も提供していただけているので、複雑な回避方法を盛り込むのは得策
ではないように思えます。

[ ]
RE:36631 ファイルサーバのソースを開いてNo.36634
秀丸担当 さん 18/06/11 14:44
 

そうですね。「このファイルはこれ以降チェックしない」もあって、許容誤差とファ
イルサイズで回避する方法もあるので、とりあえずこのままにして、原因がわかった
ということでサポートの参考情報とするまでにしておこうと思います。
従来通りにしてほしいという話があったら考えようと思います。
今まではどれだけずれるか把握していなかったのですが、V8.81でタイムスタンプが
表示されるようになったことで、許容誤差をどれだけ指定したらいいかを設定しやす
くなったと思います。

[ ]