フォーラムの返信を作成しました。

1 件の投稿を表示中 (合計 11 個)
  • 作成者
    投稿
  • seea
    参加者

    承知いたしました。 LocalFileTimeError の値で対応するようにいたします。
    回避策が見つかって良かったです。
    ありがとうございました!

    seea
    参加者

    お世話になっております。

    EmEditor v19.1.91 に更新いたしました。
    ※念のため、更新したときは毎回Windowsを再起動してから試しております。

    ・v19.1.91
    ・CFCIS はレジストリキーを削除
    ・LocalFileTimeError はレジストリキーを削除
    を試しましたところ、同様の現象が再現します(読み直しますか? のメッセージが表示されます)

    そこで、次のことを試しました。
    ・v19.1.91
    ・CFCIS のレジストリキーは無し
    ・LocalFileTimeError の値を以前ご指定の値に設定
    を試しましたところ、同様の現象は再現しません(改善されています)

    LocalFileTimeError の値が設定されていると、状況が改善されるようです。

    よろしくお願いいたします。

    seea
    参加者

    ・v19.1.0
    ・CFCIS の値は0を設定
    ・LocalFileTimeError の値をご指定の値に設定
    を試しましたところ、同様の現象は再現しなくなりました(改善されました)!

    LocalFileTimeErrorの有無で挙動が変化するようです。

    よろしくお願いいたします。

    seea
    参加者

    ・v19.1.0 に更新
    ・ご指定のレジストリのキーの新規作成
    を行いましたが、現象に変化はありませんでした。(同様の現象が再現します)

    PCの環境が変わっているので v18.6.4 を再度試すと再現しなくなりました。
    このバージョンでは大丈夫のようです。

    あらためて発生状況を確認しますと、
    ・v19.1.0 ~ v18.9.12 …… 再現する
    ・v18.6.4 …… 再現しない(問題点なし)
    となっています。
    途中のバージョンがProgramData内に無かったため、v18.6.4 ~ v18.9.12 のどこで本現象が
    再現するようになったかは分かりませんでした。

    よろしくお願いいたします。

    seea
    参加者

    ・v19.1 beta 1 (19.0.91) に更新
    を行いましたが、現象に変化はありませんでした。
    また、Windows 10 Pro バージョン 1903 の環境で試してみましたが、同じ結果となりました。
    よろしくお願いいたします。

    seea
    参加者

    お世話になっております。

    ・最新版 v19.0.0 に更新
    ・[大きなファイルを保存時、ファイル マッピングを有効にする] のチェックを解除
    を行い再度試しましたが、現象に変化はありませんでした(表題の現象が発生します)
    よろしくお願いいたします。

    seea
    参加者

    お返事が遅くなり申し訳ありません。
    おっしゃる通りネットワーク上のファイルを開いたとき発生しますが、
    ファイルサイズが小さくても発生します。比較的大きなファイルのケースは未確認です。
    また、編集して保存の操作を行わずに、既存のファイルを開いただけでも発生します。

    ————— ここから —————
    test file

    テストファイル
    ————— ここまで —————

    上記の点線で囲われた内側の内容を
    テスト.txt というファイル名で保存し(4行、29 バイト、日本語(シフト JIS))、
    このファイルを開くと発生します。再現率は100%です。
    ※試していたら偶然再現したファイルです。

    Windows 10 Pro バージョン 1809 の「ネットワークドライブの割り当て」を用いて
    ネットワークドライブをマウントしたフォルダに、上記のファイルを置いたときに再現しています。
    逆に、他の場所(C:ドライブなどの、ネットワークドライブ以外の場所)では再現いたしません。

    【参考情報】
    ネットワークドライブの元となるファイルサーバーを提供しているのは
    Samba version 4.3.1、OSは CentOS 6.10 です。
    ディスクは全てSSDです。
    また、セキュリティソフトが動いているときに起きるかなと思ったのですが、いつ試しても起きるので
    あまり関係なさそうです。
    EmEditor 18.6 では一度も起きたことがない現象なので、そのあたりに手掛かりがあるかもしれません……。

    よろしくお願いいたします。

    返信先: APPCRASH (バージョン 15.7.2) #22561
    seea
    参加者

    お世話になっております。

    本件はATOK側の問題である可能性が高いようです。
    EmEditorの問題ではありませんでした。失礼いたしました。

    「カーソル位置前後の文章を参照して変換する」をONにすると、
    エディタやWord系のアプリが落ちる場合がある障害が発生し、
    OFFにすると障害は発生しません(不具合を回避できます)。

    ATOKのツールチップの問題は、修正ありがとうございます。
    EmEditorの最新版を試してみます。

    返信先: APPCRASH (バージョン 15.7.2) #22504
    seea
    参加者

    お世話になっております。

    ■crash- で始まる名前のファイルにつきまして
    C:\ProgramData\Emurasoft\EmEditor フォルダは存在するのですが
    C:\ProgramData\Emurasoft\EmEditor\Error フォルダは存在しませんでした。
    C:ドライブを crash-* で検索してみたのですが見付かりません。

    ■再現性のテスト
    ATOK2016は、前回ご報告より更新がなく、最新版です。
    EmEditorは最新版に更新(15.7.2 → 15.8.0)いたしました。
    前回と今回の環境の違いは、以上です。

    EmEditor Professional (64-bit)
    Version 15.8.0

    前回ご報告の時、ATOK2016の設定がデフォルトのままと説明しましたが
    間違いがありました。次のオプションをONにしておりました。

    ATOKプロパティ → 入力・変換 → 変換補助 → カーソル位置前後の文章を参照して変換する
    にチェックON
    (デフォルトはOFFの設定項目です)

    ■その後の進展
    2016年2月6日のご報告の後、同様のAPPCRASHの発生回数が計5回となったのと、
    Excel 2013利用中の日本語変換においてもAPPCRASHを計6回確認したため、
    ATOK2016の問題である可能性が出てきて、ATOK2016の設定項目を見直しました。(~2月14日)
    そこで上記の設定項目を見付けたため、チェックをOFFに戻しました。(2月14日)

    一週間程度使用しましたが、APPCRASHは発生しなくなりました。
    回避策として有効な設定変更でした。

    現在、APPCRASHの再現を試みるため、
    再度「カーソル位置前後の文章を参照して変換する」をONにして(2月20日)、様子を見ているところです。

    何か状況の変化がありましたら、ご連絡いたします。

    返信先: UTF-8判別への対応 #10136
    seea
    参加者

    バージョン 10.0.5 を試したところ
    UTF-8の自動検出の件は解決しました。
    すべてのログファイルをUTF-8と認識して開くことが出来ました。
    ありがとうございました。

    返信先: UTF-8判別への対応 #9959
    seea
    参加者

    お返事ありがとうございます。
    サンプルファイルをメールでお送りします。

1 件の投稿を表示中 (合計 11 個)