検索時にエラーになります	No.00630
toshi_kan さん　16/11/14 21:04
いつも秀丸メールを利用させていただいております。 今回質問させていただくのは、「検索」⇒「検索して一覧作成」を実施したときのエ ラーです。 エラーとなる時 　・検索条件を「差出人」または「本文」などを指定した時 エラーとならない時 　・検索条件を「件名」とした時 エラーメッセージ 　「メール用のファイルが他のアプリケーションによって書き換えられたか、または 何らかの矛盾が発生しました。矛盾のある一覧を作成し直しますか？（発生箇所コー ド＝16032）」 「はい」をクリックすると 「検索処理で、メール用ファイルのサイズの矛盾を見つけました。 矛盾のあるファイル＝受信201611.txt 元のサイズ＝1216856、現在のサイズ＝1131853 検索を中断しますか？」 「いいえ」をクリックすると検索はされますが、受信フォルダ内のフォルダが変わる ごとに上記２番目のメッセージが出ます。検索を中断しなければ、検索はされている ようですが、すべてヒットしているのかわかりません。 解りずらい質問で申し訳ありませんが、アドバイスがあればお願い致します。

[ △ ]

RE:00630 検索時にエラーになります	No.00633
秀まるお2 さん　16/11/15 09:09
その、「メール用ファイルが他のアプリケーション・・・」のエラーメッセー ジは、メールデータに何からの矛盾を見つけた時に出るエラーになります。その エラーが出たとしても、その「一覧を作成しなおしますか？」で「はい」と応答 すれば、メール一覧が正しく修復されて、以後は出ないはずになります。 　一覧の作成しなおしをしても、もう一度検索をすると同じエラーを繰り返すっ てことですよね。 　もしそうだとしたら、根本原因は、何かハードディスクに問題があるんじゃな いかと思うので、とりあえずやってみて欲しいことを書かせていただきます と・・・ 　１．ハードディスクのエラーチェックをかける。 　　　「Windows7 ハードディスク エラーチェック」のようなキーワードで 　　　ネット検索するとやり方が出てきます。 　２．メールデータの保存場所が、何かのネットワークドライブ上である 　　　場合は、一回、パソコン内蔵ハードディスク上に移動してどうか 　　　試してみる。 　　　（特にNAS製品の場合とか、Windows以外のOSで動いてるサーバー 　　　　上の場合） 　３．例えば「受信」フォルダに限ってエラーが出るのであれば、受信 　　　フォルダのメールを一度別のフォルダに移動してからまた元の 　　　フォルダに戻す。 　辺りでどうでしょうか。 　もしそれでもダメでしたら、もうちょっと状況を教えて欲しいです。 　１．エラーが出るのは特定のフォルダに限定されてるのかどうか、 　　　さらには特定のフォルダで出るにしても、毎回同じファイル 　　　（受信201611.txtに限って出る？）のかどうか。 　　　限定されてないとしたら、例えば全体で１００個くらいあるフォルダ 　　　のうち５０個くらいで出るとか、特定のアカウント配下のすべての 　　　フォルダで出るとか、何かもうちょっとヒントが欲しい。 　２．メールデータを置いてある場所は、内蔵ハードディスク上か、 　　　外付けUSB接続のハードディスク上か、何かネットワークドライブ 　　　上だとしたら、それの製品名は何か。 　　　USBメモリだとしたら、例えば以前トラブルのあった例として、 　　　独自のパスワードツール（暗号化ソフトウェア）付きの物か 　　　どうか。 　３．念のため、Windowsの種類が何かも。 　４．セキュリティ用にインストールしてるソフトウェア製品が何か、 　　　その他、何か、パソコン全体に影響するようなソフトウェア製品 　　　を利用しないかどうか。（例えば自動でバックアップしたり暗号化 　　　したり、クラウドストレージと同期したりする物とか） 　辺り教えて欲しいです。

[ △ ]

RE:00633 検索時にエラーになります	No.00638
toshi_kan さん　16/11/15 20:15
コメントありがとうございます。 実は、会社で使っているメールなのですが、会社の環境がシンクライアントなもので すから、物理的なチェックはできないと思います。 シンクライアントになってから数年たちますが、特に問題はありませんでした。 最近、「info cage」なるシステムが導入され、ほとんどのファイルが暗号化されま した。秀丸メールのテキストも暗号化されましたが、テキストファイルを秀丸メール で使えようにプログラム登録をしております。 上記が、利用している環境です。（OSはwindows7 32bit) 1.エラーは特定のファイルだけではありません。 　※受信201611.txtは例で有り、違うフォルダでは201610.txtとかいろいろです。 （フォルダ単位と思います） 2.メールデータは上記の通り、仮想環境のネットワークドライブになります。 3.windows7 32bit 4.上記記入の通りです。 最初の質問時に使用している環境を書けば良かったです。申し訳ありません。 何かまだ情報が足りなければ、教えてください。 よろしくお願い致します。

[ △ ]

RE:00638 検索時にエラーになります	No.00639
秀まるお2 さん　16/11/16 09:40
たぶん、暗号化ソフトウェアのせいで、ファイルサイズが正しく取得出来てな いのかなぁと思います。それでエラー扱いしてしまってるんだと思います。 　ちょっと話がそれますが・・・ 　実は、NECの暗号化ソフトウェアのために、秀丸メールに１つオプションがあ りまして、それを使うと暗号化を回避できるというのがあります。 　「全般的な設定・上級者向け・その他・その他２」 　に、 　□ .txtファイル拡張子を.txt_nsecに変更する等 　がありまして、それをONにすると、メールデータが勝手に暗号化されるのが回 避できます。 　それを使わなくても暗号化を回避できてるのなら、使わない方がいいですけど も・・・。以前ユーザーさんとやりとりして話をした限りでは、暗号化する/し ないの指定はユーザー側に権限が無いがためにコントロールできなくて、そうい うオプションが必要ということで対応したのでした。 　その話はとりあえず置いといて・・・ 　元のエラーの件に戻ります。 　実は、普段メールを表示したりする時は、メール用ファイルのサイズがおかし いかどうかのチェックは、メール用ファイルを読み込んでエラーになった場合に のみチェックするようにしてます。検索の時は、メール用ファイルを読み込む前 に、GetFileSizeっていうWindowsのAPIでサイズを調べて、それが以前のサイズ と違ってたらエラーを出すようにしています。 　たぶん、GetFileSizeが正しく動作してないだけで、実際にはファイルの読み 込みは正しく動作してるんじゃないかと思います。例えば今回のケースだと、 元のサイズ＝1216856、現在のサイズ＝1131853 　ということで、GetFileSizeで得られたファイルサイズが小さめになってしま ってるんですが、実際にはReadFileで読み込めば元のサイズ分読み込めるんじゃ ないかと思います。 　ということで、とりあえずサイズチェックを省略してファイルの読み込みをや ってみて、それでもしも、本来のサイズ分読み込みが出来なかったらエラーを出 すって風にしてみようと思います。 　次のβ版でやってみます。今週中にアップロードさせていただきます。少々お 待ちください。

[ △ ]

RE:00639 検索時にエラーになります	No.00640
toshi_kan さん　16/11/16 19:07
レスポンスの早さにびっくりしております。通常のソフトウェアサポートはこんなに 速く、回答はいただけないです。 「info cage」は暗号化はされるのですが、秀丸メールを登録することで、複合して いることだと思っています。 これは余談としまして。。。 □ .txtファイル拡張子を.txt_nsecに変更する等 につきましては、今は設定しないこととします。 β版を用意していただけるなんて、なんだか申し訳ありません。 用意していただければ、すぐに試してみたいのですが、会社のメールですので平日の 日中帯に確認をして、帰宅後にその結果を報告させていただきます。 ご面倒をおかけ致しますが、よろしくお願い致します。

[ △ ]

RE:00640 検索時にエラーになります	No.00641
秀まるお2 さん　16/11/17 10:58
今アップロードしたので、すみませんがそれでテストお願いします。 　エラーが出たら、その内容を教えて欲しいです。 　GetFileSizeで取得したサイズが以前と違ってたら、さらにFindFirstFileで サイズとタイムスタンプ（Last write time）を取得して、サイズもタイムスタ ンプも違ってたら、実際にファイルを読み込むテストをして、読み込んだサイズ も元のサイズと違ってたらエラーを出します。 　それでエラーが出るなら、何らかの理由でメール用ファイルが、秀丸メール外 で（たぶんInfoCageさんに）書き換えられてるんじゃないかと思います。 　もしそうだとしたら・・・ 　とりあえず、「全般的な設定・上級者向け・デバッグ」の中にある 　　□ メール用ファイルの読み込みエラーを無視する 　をONにするとエラーメッセージは出なるかもしれませんが、本当にメール用 ファイルが書き換わってるなら、やはり別の所でエラーが出るかもしれません。 　それの他には・・・ 　この前話した「.txt_nsec」にするオプションを試していただく作戦もありま す。それでInfoCageさんによるメールの改変（？）が回避できるかも・・・。 　よろしくお願いします。 32bit版： http://hide.maruo.co.jp/software/bin3/hmmail660b1_signed.exe 64bit版： http://hide.maruo.co.jp/software/bin3/hmmail660b1_x64_signed.exe

[ △ ]

RE:00641 検索時にエラーになります	No.00674
toshi_kan さん　16/11/21 19:59
早速対応していただきありがとうございます。本日確認をした結果をお知らせ致しま す。 結果としましては、別のエラー（下記メッセージ）がフォルダごとに出ます。 「ReadFileに失敗、nError=0 name=Y:\TurukameData\kanno\受信\受信201611_01.txt  offset=64856 cbMail=1927 cdRead=4503 FileMan.cpp(16379)error=0 ご面倒でなければこのエラーの再現手順を。。。。dump.txtの内容を作成者に連絡く ださい。。。。。。」 のメッセージがフォルダをまたぐごとに出てきます。 Subjectでの検索は今まで通り、問題なく検索できます。 dumpファイルはセキュリティの関係からも提供は難しいです。 大変申し訳ありませんが、ご確認をお願い致します。 β版をインストール後に上記の状態でしたので、6.60の正式バージョンが出ていまし たので、正式版をインストールしましたところ、β版と同じエラーになりました。 （自分としては、β版インストール前と同じエラーになると思っていました が。。。。） 以上、よろしくお願い致します。

[ △ ]

RE:00674 検索時にエラーになります	No.00675
秀まるお2 さん　16/11/22 11:49
エラー情報どうもです。 　とりあえず、前回のエラーを回避する用に作った処理は正常動作してるようで すが、後々のファイル読み込みでやはりエラーが出るということで・・・ 　他の回避策としては・・・ 　１．メール用ファイルの読み込みを、とにかく一括して実行するタイプ 　２．メール用ファイルの読み込みを、メールを表示する時と同じ 　　　タイプにする。 　の２種類を用意して、今、V6.61β1としてアップロードしました。これの オプションをいじってエラーが回避できるかどうか試してみて欲しいです。 　「全般的な設定・上級者向け・デバッグ・デバッグ2」の所に追加してます。 　「検索時のファイル読み込みでエラーが出る対策」をまずONにして試してみて、 それでダメな場合は「その２」の方もONにして試してみて欲しいです。 　それでもダメな場合は・・・、すみませんが回避不能だと思います。 　ダメな場合、「全般的な設定・上級者向け・動作の記録」の「秀丸メールの動 作をdump.txtに記録する」をONにした上で「…エラーが出る対策」のみONにして 実行すると、     READFILE_BIG: ReadFile failed, code=nnnn cbRead=nnnn cbFile=nnnn 　みたいな記録が出るかもしれません。もしそれがあったら、その１つだけでも 教えて欲しいです。 ダウンロードURL 32bit版： http://hide.maruo.co.jp/software/bin3/hmmail661b1_signed.exe

[ △ ]

RE:00675 検索時にエラーになります	No.00676
toshi_kan さん　16/11/22 19:28
無事解決致しました！！大変ありがとうございます。 ご教示いただいた通り、 1.「検索時のファイル読み込みでエラーが出る対策」をまずON 　⇒やはり同様のエラーが出ました。 2.それでダメな場合は「その２」の方もONにして試してみて欲しいです。 　⇒エラーも出ずに検索せきました。 試しに、１をOFFにして「その２」のみをONにしてもエラーが出ずに検索ができました。 検索に少し時間がかかるような気はしますが、問題ないと思います。 ご対応いただき誠にありがとうございます。 これからも秀丸メールを使っていこうと思いますので、今後ともよろしくお願いいた します。

[ △ ]

RE:00676 検索時にエラーになります	No.00677
秀まるお2 さん　16/11/22 23:03
「その２」の方で直ったということで・・・。なぜ直るのかちょっと謎ではあ りますが、とりあえず良しということにさせていただきます。 　同じ環境のユーザーさんから同じような問い合わせがあった時は、この オプションで回避をお願いする作戦にしようと思います。

[ △ ]

RE:00630 検索時にエラーになります	No.00708
もみじ さん　16/12/03 13:35
いつも秀丸メールと秀丸エディタを利用させていただいており感謝しています。 本題ですが、 本検索時のエラー申告の方と、たぶん私は同じ会社に勤務しています。 8月に私の職場で導入されて同様の事象が発生していたのですが、infocageという特 殊な暗号化システムが入っているため対応をお願いするのも申訳ないと思い、会社推 薦のoutlookに移行していました。 outlookは非常に使いづらく我慢していたのですが、本件で対応していただいたので 私も秀丸メールに再度移行しました。 機能追加いただいた、その２の方で検索自体は使えるようになりました。ありがとう ございます。 しかし、拡張子がtxtのファイルが添付されたメールを受信したときに、受信のファ イル名が"retried-file.bin"となり、メールヘッダの部分に"Cannot create attache  file,filename=AAAA\BBBB.txt,error-code=5"のように表示されます。 色々試してみたのですが、他者から送られてきたTXT添付メールの場合、AAAAの部分 が"?Yt"のように化けます。自分で自分に送った場合は、AAAAの部分は化けずに表示 されるようです。 また、BBBBのファイル名も他者からのは化けますが、自分からのは化けません。 また、retried-file.binをエディタで開くと、内容的には送られてきたテキストファ イルそのままです。 何か参考になる情報は無いかとdumpを見てみましたが、retried-file.binのログの後 にいつも"DontProcessAnyCommand=FALSE"と記録されています。 以上、ご確認方よろしくお願いいたします。

[ △ ]

RE:00708 検索時にエラーになります	No.00709
秀まるお2 さん　16/12/03 17:50
エラーコード５というのは、 // // MessageId: ERROR_ACCESS_DENIED // // MessageText: // //  Access is denied. // #define ERROR_ACCESS_DENIED              5L 　のように定義されてる物で、一般にはファイルの排他制御で出るエラーになり ます。どっちにしてもInfoCageさんが介在してる（APIをフックして何か細工し てる）のが関係してるんだと思います。 > 色々試してみたのですが、他者から送られてきたTXT添付メールの場合、AAAAの部分 > が"?Yt"のように化けます。自分で自分に送った場合は、AAAAの部分は化けずに表示 > されるようです。 　たぶん、メールの文字コードが欧文/中国語/韓国語/ロシア語か何かのせいじ ゃないかと思います。その場合、エラーを表すヘッダに無理矢理「受信添付」っ て日本語文字コードを入れてるせいで、そこが化けて見えることはありえます。 　問題のメールの文字コードは、メールをエディタで開いて「設定 - 文字 コード」サブメニューの中のチェックの入ったのが何かで分かります。それが分 かれば、ご自身からご自身宛に、同じ文字コードのメールで添付ファイル付きの を送ってみれば、現象が再現できるんじゃないかと思います。 　とりあえず、現象が再現できればなおありがたいです。 　「全般的な設定・上級者向け・動作の記録」のdump.txt作成オプションをONに していただけると、この辺のエラーについての情報も何か出てるかもしれません。 　対応策としては・・・添付ファイルの生成時のCreateFileでエラーになったら、 拡張子に「_nsec」を付加して再試行するようなロジックを入れる作戦ならどう かなぁと思います。「.txt」でダメでも、たぶん「.txt_nsec」だとうまくいく んじゃないかと思いますけども。 　他に、何かこういう動作なら行けそう、みたいな案があれば教えて欲しいし、 無ければ、とりあえず「_nsec」付きで再試行するバージョンを作ってみたいと 思います。

[ △ ]

RE:00709 検索時にエラーになります	No.00710
もみじ さん　16/12/03 19:52
お返事ありがとうございます。 添付のファイル名が化ける件ですが、自分自身で送った場合（秀丸メールから自分宛 に送り、秀丸メールで受信）した場合も同様にファイル名が化けてしまいます。 dump.txtですが、すべての送受信を記録するようにしたのですが、明確にエラーとな っているような先に書いたFALSE以外の記録はありませんでした。 dump.txt自体をお送りすることはできないので、もし、調べる場所をお教えいただけ ればその部分を抜粋して提示いたします。 あと、ヒントになるかどうか分りませんが、infocageは、動作的にwindowsフォルダ、 program filesフォルダ以外のフォルダが自動暗号化の対象フォルダとなります。 その暗号化対象となるフォルダにtxtやxlsなどの暗号化対象ファイルが置かれだだけ では暗号化されません。暗号化は当該ファイルを開いた後にされる仕組です。 エラー5は排他処理関係とのことなので、txtが添付され送られてきたメールをデコー ドして、BBB.txtとした時にinfocageによる暗号化がかかり、その後の秀丸メールの 処理時に引っかかっているのかなと想定しました。 もしそうなら、txtファイルをデコードする際に仮のファイル名をつけておいて、最 後にファイル名を本来のものにすれば回避できるような気がしました。（勝手な推測 で申訳ありません）

[ △ ]

RE:00710 検索時にエラーになります	No.00711
秀まるお2 さん　16/12/04 18:34
> エラー5は排他処理関係とのことなので、txtが添付され送られてきたメールをデコー > ドして、BBB.txtとした時にinfocageによる暗号化がかかり、その後の秀丸メールの > 処理時に引っかかっているのかなと想定しました。 　秀丸メール側での、添付ファイルを生成する処理を見直した所・・・ 　普通のShift-JIS文字コードのメールの場合だと、添付ファイルはCreateFile で生成して書き込みしてCloseHandleするっていう、シンプルな処理をするだけ でして、その場合にInfoCageさんの排他処理がかかることは無いように思います。 　排他処理がかかりそうな処理としては、例えばメールの文字コードがUTF-8の 場合で、メールの中で使われてる文字がShift-JIS範囲内の文字しか無い場合、 一度UTF-8してデコード（＆添付ファイル生成）してからShift-JISに強制変換す るモードでもう一度デコードしなおしをします。 　その場合、一度添付ファイルを生成してから削除してまた同じ名前のファイル を生成しなおす、という、ちょっと効率の悪い処理が働きます。 　そういう場合のケースなんじゃないかという気がします。 　その場合とは逆のケースもあります。メールの文字コードがShift-JISと指定 されてても、ヘッダの中に、例えば「=utf-8?b?....?=」みたいな形でShift-JIS 範囲外の文字があると、そのメールはUTF-8に強制変換される方式でデコードし なおしとなります。 　それらの場合、 X-Body-Content-Type: text/plain; charset=iso-2022-jp (original=UTF-8) 　みたいにcharset=の指定の後ろにoriginal=xxxxみたいな補足がつきますけど も。 　とりあえず、そういうケースと断定できるようでしたら、添付ファイルを２回 生成しなおす処理を直す形で「retried-file.bin」となるのを回避できるように 思います。 　その辺どうでしょ？

[ △ ]

RE:00711 検索時にエラーになります	No.00712
秀まるお2 さん　16/12/05 09:51
今テストしてるんですが、添付ファイルを生成しなおすケースじゃなくても起 きてる前提で話をさせていただくと・・・ 　元々の話にある「添付ファイルのファイル名が化ける」というのが問題かもし れなくて、そうだとすると、具体的にどう化けてるのか分からないと困ります。 　例えば添付ファイルのファイル名が「a.txt」で、メールが普通の日本語の メールだとしたら、    X-TuruKame-Error: 　ヘッダに出てくるファイル名は、「受信添付\161205_01\a.txt」みたいな名前 になるはずで、それが化けるとしたら、「受信添付」の日本語部分が化けて出て くるのか・・・。それとも「a.txt」の部分が何か違う内容になるのか・・・。 　１．メールの文字コードは普通の日本語 　２．添付ファイル・ファイル名は「a.txt」 　３．自分から自分に送っても現象が起きる。 　という前提だとしたら、 　４．その場合のX-Attach:ヘッダの内容、およびX-TuruKame-Error:ヘッダの 　　　内容。 　を教えて欲しいです。 　ここの会議室に書き込み不可の場合は、"maruo@mitene.or.jp"宛にメールでお 願いします。

[ △ ]

RE:00711 検索時にエラーになります	No.00721
もみじ さん　16/12/05 22:45
お返事遅くなりました。 感覚的に中間ファイルを作成しているところが、そうなのかなと思いました。 なぜならば、エディタ（秀丸エディタに限りません）で適当な文字を入れて デスクトップにccc.txtのようにエディタを保存と同時に終了させて、間髪 開けずに同ファイルを開こうとすると排他がかかっているとメッセージが でますので。 エンコードの件ですが、普通のS-JISコードのメールというのをどうやって 作ればいいのか分らないのですが、以下のようにテストしてみました。 (1)秀丸→秀丸：受信側のヘッダで見た文字コートはiso-2022jp、添付の中身はSJIS (2)サンダーバード→秀丸：同上 (3)秀丸→秀丸：文字コードをiso-2022jp(original=utf-8)、添付の中身はSJIS その結果ですが、(1)-(3)とも同じくエラー5(retried-file.bin)になりました。 他の確認方法があればやってみますのでお教えください。 ＃会社に行かないと試せないのでお返事は少し遅くなりますが、、、

[ △ ]

RE:00677 検索時にエラーになります	No.00723
もみじ さん　16/12/05 22:55
>　「その２」の方で直ったということで・・・。なぜ直るのかちょっと謎ではあ >りますが、とりあえず良しということにさせていただきます。 私も「その２」にしないとエラーになるのですが、エラーの内容をお知らせします。 何かのお役に立てば幸いです。 ReadFileに失敗、nError=0 nameC:\xxx(フォルダ名)xxx201611.txt offset=0 cbMail=4757 cbRead=14286 FileMain.cpp(1638)error=0 秀丸メールのバージョンは、661b1です。 もしかして、dump.txtの中身もあった方が良かったかもですね、、、いま気がつきま した。

[ △ ]

RE:00721 検索時にエラーになります	No.00726
秀まるお2 さん　16/12/06 10:03
> エンコードの件ですが、普通のS-JISコードのメールというのをどうやって > 作ればいいのか分らないのですが 　S-JISコードというのはすみませんが間違いで、普通に日本語文字コードの メールで作って欲しいという話になります。やり方は、普通に「新規メール」と してメールを作成すれはいいだけです。 　「新規メール」とした後に「設定 - 文字コード - 多国語混在ユニコード」と か選ぶといけないという、ただそれだけの話です。 > ＃会社に行かないと試せないのでお返事は少し遅くなりますが、、、 　普通の日本語文字コードのメールでもretried-file.binになってしまうという ことで・・・。一応、普通の日本語文字コードのメールの場合はファイルを生成 した後にもう一度アクセスする処理はしてないはずなんですが、その辺もう一度 確認してみます。 　あと、00722番発言の方は、個人情報が含まれてると思うので、削除させてい ただきます。お返事が遅れる件は了解しました。

[ △ ]

RE:00723 検索時にエラーになります	No.00727
秀まるお2 さん　16/12/06 10:14
エラー内容どうもです。 　エラー内容的には、最初に取得したサイズ分をReadFileで読み込もうとしても、 なぜかその分読み込みできず、少ない分しか取得できてなくてエラーになってる ようですが、なぜそうなるのかは分かりません。 　「その２」で回避できる理由もよく分からずです。 　ファイルを書き込みした時に「ここからここまで書き込んだ」みたいなのを InfoCageさんが覚えてて、それと同じ部分をReadFileすれば正常にアクセスでき る、だけども、違う範囲をReadFileすると期待通りに読み込めない、みたいな仕 組みなのかなぁと思います。

[ △ ]

RE:00712 検索時にエラーになります	No.00735
秀まるお2 さん　16/12/06 17:26
ちょっと話が先走ってしまって申し訳無いですが、先ほどVersio 6.61β3を急 いでアップロードする必要がありまして、そのついでに、こちらの「retried- file.bin」になる対策も入れてしまいました。 　添付ファイルを生成する用のCreateFileでエラーコード5が返った場合、例え ば添付ファイルのファイル名が「a.txt」なら、    a.txt_nsec 　の名前でファイル生成テストをしてみます。それに成功したら、とりあえずそ の名前で添付ファイルの書き込み＆クローズをします。 　その後、ファイル名を変更しようと試みます。 　MoveFileってAPIで、a.txt_nsecをa.txtに名前変更しようとします。 　もしそれに成功したら、そのまま「a.txt」としてファイルが生成されたよう な形になります。 　失敗したら、「a.txt_nsec」のままで添付ファイルを生成する形になります。 　最悪でも「a.txt_nsec」になるので、前よりはマシかと思います。 　お時間のある時でいいので、ぼちぼちインストール＆テストお願いします。 　といってる間に正式版にしてしまうかもしれません。（ちょっとまずいバグが １件見つかってしまいまして）

[ △ ]

RE:00735 検索時にエラーになります	No.00737
もみじ さん　16/12/06 21:31
> >　お時間のある時でいいので、ぼちぼちインストール＆テストお願いします。 > こんばんは。 ご対応ありがとうございます。 明日職場で試してみます。

[ △ ]

RE:00726 検索時にエラーになります	No.00738
もみじ さん　16/12/06 21:45
お世話になります。 出張前に確認できたので報告いたします。 3メールから抜粋しました。 X-TuruKame-Error: Cannot create attach file, filename=?Yt\161205_13\?k???xt,  error-code=5 X-Turukame-Error: Cannot create attach file, filename=?Yt\161205_13\retried- file.txt, error-code=5 X-Attach: 受信添付\161205_13\retried-file.bin X-Boby-Content-Type: text/plain; charset="iso-2022-jp" X-TuruKame-Error: Cannot create attach file, filename=?Yt\161202_05\20161130 _}g@l?c.txt, error-code=5 X-Turukame-Error: Cannot create attach file, filename=?Yt\161202_05\retried- file.txt, error-code=5 X-Attach: 受信添付\161202_05\retried-file.bin X-Boby-Content-Type: text/plain; charset="iso-2022-jp" X-TuruKame-Error: Cannot create attach file, filename=?Yt\161124_900\IoT??tx t,error-code=5 X-Turukame-Error: Cannot create attach file, filename=?Yt\161124_900\retried -file.txt, error-code=5 X-Attach: 受信添付\161124_900\retried-file.bin X-Boby-Content-Type: text/plain; charset="iso-2022-jp"(original="UTF-8") こんな感じでおわかりでしょうか？ よろしくお願いいたします。

[ △ ]

RE:00738 検索時にエラーになります	No.00739
秀まるお2 さん　16/12/06 22:18
情報ありがとうございます。 　「?Yt」となる部分は、本来「受信添付」のようにならないといけない部分で して、ここが肝心な部分でありつつ、まったくもって謎の部分であります。 　なぜこういうことが起こりうるのか考えて、なんとか回避策が無いか考えてみ ます。

[ △ ]

RE:00735 検索時にエラーになります	No.00740
もみじ さん　16/12/07 21:21
こんばんは。 早速ver 6.61β3で試してみました。 ファイル名に2バイト文字と1バイト文字両方でやってみましたが共に _nsecがつきま した。 添付試験.txt →　添付試験.txt_nsec a.txt →　a.txt_nsec dump.txtを見ると以下のようになっていました。 Decoding BASE64 size=18 sum=1309 cec=6CE96757 start="g2WDWINnDQoNCg==.. Result: size=10 sum=731 crc=2C723C05 cCR=1 cInvalid=0 Attache-file create error, code=5, trying _nsec, path=受信添付\161207_21\添 付試験.txt _nsec MoveFile failed, code=183 filter action=00000001 filterlog.txt nolog Added.bin (メアド)/6/ file=受信ログ201612_18.txt offset=869822 added.bin done 解決の参考になれば幸いです。

[ △ ]

RE:00740 検索時にエラーになります	No.00741
もみじ さん　16/12/07 21:46
自己レスですみません。 エラーコード 183ってもしかするとERROR_ALREADY_EXISTSでしょうか。 やはり何かinfocageが影響（わるさ）しているのかもですね。

[ △ ]

RE:00741 検索時にエラーになります	No.00742
秀まるお2 さん　16/12/08 08:51
またまた情報ありがとうございます。 　MoveFileしようとしてそのエラーが出てるということは、たしかにファイルが 既に存在してることになります。 　例えば１つのメールに「a.txt」が２つ付いてる場合とかもメールではありえ るんですが、そういうケースだと、普通は２個目のCreateFileの段階で ERROR_ALREADY_EXISTSのエラーが返って、結果、２個目のファイル名を 「a(2).txt」に変える処理をします。もしもファイル生成直後に暗号化が働くと、 本来返るはずのERROR_ALREADY_EXISTSがERROR_ACCESS_DENIEDになるのは理にか なってると思います。 　今回そういうケース（同じ名前の添付ファイルが２つ付いてる）では無いはず だとは思うんですが、そういうケースだとしてもうまく動作するように修正して みます。 　それとは別に、たぶん暗号化の処理が終わるまで待ってからアクセスすれば大 丈夫だろうという予想もしてまして、少々待ってからアクセスしなおす処理も作 ってみました。（これは昨日の段階で） 　それで大丈夫になりそうな気がします。 　dump.txt出力もいっぱい追加しました。 　今日中にV6.61β4をアップロードさせていただきます。少々お待ちください。

[ △ ]

RE:00742 検索時にエラーになります	No.00745
秀まるお2 さん　16/12/08 15:06
Version 6.61β4として今アップロードしました。 　これで、問題のメールを受信解析して、dump.txtの内容や結果など教えて欲し いです。 　もしダメでしたら・・・ 　「全般的な設定・上級者向け・デバッグ・デバッグ２」に 　「受信解析時に添付ファイルが生成ミスになる対策」 　ってオプションがあるので、それをONにしてまた試してみて欲しいです。 　とりあえず、β3の段階で「.txt_nsec」にはなるようになったので、最悪これ で使っていただく作戦もありかなぁと思ったりしますが、一応、今回の修正で直 ってくれてるかなぁと思います。 　入れた対策は： 　−　同じ名前の添付ファイルを生成しようとしてるかどうかの確認に、 　　　CreateFileのエラーコードを見る方式をやめて、生成した添付ファイルの 　　　ファイル名を覚えておいて比較する方式にした。 　−　添付ファイル生成でACCESS_DENIEDになった場合は、FindFirstFile、 　　　SetFileAttributes、DeleteFileで既存のファイルを削除する試み、 　　　＆、CreateFileしなおす処理を最高１秒繰り返すようにした。 　−　１秒繰り返してもダメだったら、「.txt_nsec」で生成を試みるように 　　　した。それでもダメなら「retried-file.bin」になる。 　−　「.txt_nsec」で生成に成功したら、それをリネームで元に戻す前に、 　　　同じ名前のファイルがあるか調べて、もしあったら削除を試みて 　　　からリネームするようにした。 　など、考えられる対策をいろいろ入れました。また、dump.txtもかなり追加し ました。 　よろしくお願いします。 32bit版： http://hide.maruo.co.jp/software/bin3/hmmail661b4_signed.exe 64bit版： http://hide.maruo.co.jp/software/bin3/hmmail661b4_x64_signed.exe 　VirusTotalおよびKaspersky Online Scannerでウイルス誤検知されないことも 確認しています。

[ △ ]

RE:00745 検索時にエラーになります	No.00750
もみじ さん　16/12/08 17:26
驚くほど迅速に対応いただきありがとうございます。 本日、例によって出張中のため明日出社して確認します。 ご報告は夜になると思います。 よろしくお願いいたします。

[ △ ]

RE:00745 検索時にエラーになります	No.00763
もみじ さん　16/12/09 22:30
β4ありがとうございました。 本日試してみました。 結論から言うと、そのままでも「受信解析時に添付ファイルが生成ミスになる対策」 をONにした時でも両者とも正常にデコードされました。 テストしたのは以下になります。 (1)自分（秀丸メール）から自分へ送信 (2)過去受信のファイル名が化けているメールを「受信解析のやり直し」実施 (3)過去受信のファイル名がretried-file.binになっていたメールの「受信解析のや り直し」実施 これらについて、「生成ミスににある対策」をオン、オフの両方をやり、dump.txtを 見てみましたが 特段のエラー類は出ていないようです。 ただ、オンにした場合、複数回メールの受信と解析が行われているように見えました。 ＃ループ処理の関係でしょうか？ あと、オンの場合、上記の関係だと思いますが、受信処理時間がかなり長引くようで す。 また、秀丸メール自体の問題では無いと思うのですが、infocageが働いているせいで、 メール表示ウィンドウに表示される添付ファイルに付与されるファイルサイズが、受 信直後した 状態を維持すると実際のファイルサイズが表示され、いったん秀丸メールを落して再 起動すると 先の添付ファイルのサイズが大きくなっていました。 サイズが大きくなる理由は、infocageが86-87KB付与するためですので秀丸メール自 体に問題が あるわけではありません。（ご参考情報として） ということで、「生成ミス対策」を利用するしないに関わらずtxtファイルのデコー ドが成功しましたが、 dump.txtから私の目では何がどうしているのか分りませんでした。 もし、dump.txtから抜粋すべきところがあればご提供しますのでお知らせください。 なお、セキュリティポリシーの件で会社端末には色々な仕組が組込まれており、外部 への情報持出し、 メール添付、掲示板へのコピペが制限されているので、必要な部分をメモして帰宅し てからアップする ということをしています。 なので、抜粋すべきところがあれば教えていただければ助かります。 よろしくお願いいたします。

[ △ ]

RE:00763 検索時にエラーになります	No.00766
秀まるお2 さん　16/12/10 00:22
とりあえず直ったということで・・・本当はdump.txtの中身を教えて欲しい所 ではあるんですが、いくつか入れた対策のうちのどれかが当たったんだと思うし、 それらの処理はそのまま残しておいて支障ないものなので、そのままってことに させていただきます。 　追加した「生成ミスになる対策」のオプションは廃止させていただきます。 　このオプションは・・・例えばメールの文字コードがutf-8だけど最終的にJIS に変換した場合、以前お話した通り、添付ファイルを２重に生成しなおしてしま うんですが・・・・、オプションOFFの場合、１回生成して２回目生成する前に １回目に生成したのを削除します。オプションONの場合、１回生成して次に再生 成したくなっても前のファイルは残したまま２回目のファイルを生成し、その後、 １回目に生成したファイルを削除するっていう、 　１回目生成 --> 1回目削除  -->  2回目生成 　の順次が、 　１回目生成 --> 2回目生成  -->  1回目削除 　みたいな順序になるようにしています。とりあえずこれだと遅くなる（たぶん ２重にInfoCageが暗号化する）ってことだしいいこと無さそうなので、次のβ版 では廃止させていただきます。 　とりあえず良しということで、もし他に何も無ければこの件は終了させていた だきます。

[ △ ]

RE:00766 検索時にエラーになります	No.00770
もみじ さん　16/12/10 18:03
>　とりあえず良しということで、もし他に何も無ければこの件は終了させていた >だきます。 ありがとうございました。 あと、色々ご対応いただいたのにどこが効いているかお知らせできないというのも心 苦しいので ちょっとお時間いただきますが、dump.txtの情報お伝えできるように考えてみます。 何はともあれ、まずはお礼まで。

[ △ ]

RE:00770 検索時にエラーになります	No.00771
秀まるお2 さん　16/12/10 18:17
dump.txtに出てる情報で何が分かるかだけ連絡させていただきます。     Attach-file CreateFile access denied, trying 1sec 　があって、     AttachFile CreateFile retry succeeded. 　があれば、CreateFileで失敗した後に１秒間CreateFileを繰り返し再試行する 処理で成功したことになります。     Attach-file CreateFile retry failed. 　があれば、１秒繰り返してもやはりCreateFile出来なかったことになります。 その場合、「.txt_nsec」で試行する処理に行きます。     Attach-file create error, code=5, trying _nsec, path=xxxx 　が出ます。その後、     _nsec MoveFile failed, code=XXXX 　があれば、ファイル名変更に１回失敗してて、その後、     MoveFileEx(replace) succeeded 　があれば、無理矢理ファイルを上書きする処理が成功したことになります。 　たぶんどっちかの処理が成功してるんだと思います。 　ちなみにですが、前者の「trying 1sec」の処理は、その名の通り１秒間しか 再試行しないので、もしも暗号化に１秒よりもっと時間がかかると失敗する可能 性があります。例えば極端にサイズの大きい添付ファイルだとダメかもしれませ ん。それも１回テストしていただいた方がいいかもしれません。

[ △ ]

RE:00771 検索時にエラーになります	No.00779
もみじ さん　16/12/12 23:48
こんばんわ。 添付ファイルのデコードにかかっていると思われる部分のログを取得しました。 この後、メールでお送りいたします。 素人目で見ると、ご指摘のエラーがでていないような気がしていますが、、、、

[ △ ]

RE:00779 検索時にエラーになります	No.00780
もみじ さん　16/12/12 23:55
いま過去のやりとりで送先のメアドを探したのですが、SPAM対策だと思いますが削除 されているのですね、、、、

[ △ ]

RE:00780 検索時にエラーになります	No.00781
秀まるお2 さん　16/12/13 09:50
僕のメールアドレスは"maruo@mitene.or.jp"なのですが、先ほど書いたいろん な記録（CreateFile Access denied等の記録）が出てないのなら、なぜだか分か りませんが正常動作のパターンに戻ってるってことなんだと思います。だとした ら、ログを送っていただかなくてもいいです。 　何か別の理由（別の修正箇所のせい？）で直ったのやら？

[ △ ]

RE:00739 検索時にエラーになります	No.00797
もみじ さん　16/12/17 15:29
お世話になります。 ご連絡遅くなりましたが、当該事象について参考になればとデータをメール致しまし た。 ご確認方よろしくお願いいたします。

[ △ ]

RE:00781 検索時にエラーになります	No.00798
もみじ さん　16/12/17 15:30
お世話になります。 ご連絡遅くなりましたが、当該事象についてデータ提供不要ということではあります が何かの参考になればとデータをメール致しました。 ご確認方よろしくお願いいたします。

[ △ ]

RE:00798 検索時にエラーになります	No.00803
秀まるお2 さん　16/12/19 08:52
PDFファイル２つ届きました。 　まず、X-TuruKame-Error:ヘッダの中身が化ける件は、これについては実はこ ちらで原因を究明できて修正も出来ていました。その辺連絡してなくてすみませ んでした。 　UTF-8文字コードのメールで添付ファイル生成のエラーが起きると化けてしま ってました。 　最新版では化けないようになっています。 　それと、添付ファイルのファイル名がおかしくなる件も、送っていただいた ログだとやはり僕の作ったいろんな処理（１秒間再試行したりファイル名を変え て生成したりする処理）が全然通って無くて、普通に添付ファイル生成に成功し てしまってるようです。なぜかちょっと分かりません。 　もしかしてここの会議室の話をInfoCageの開発者さんが見てて、そっちに何か アップデートがあったとか。 　とりあえず直ってるので良しとさせていただきます。

[ △ ]

---