メールが増殖？ - 秀丸メール情報交換会議室 - スレッド29844, 2007/01/12

メールが増殖？

hajimett さん　07/01/12 12:21

秀丸メール　いつも便利に使っています

さて、
この度はなんと表現して良いのかちょっとおかしなコトになっているので
ご報告とともにどうしたものかご示唆が得られればと思い投稿します

環境：
秀丸メールをデスクトップとノートとで
同期して運用している
秀丸メールver4.69

現象：
Date: Mon, 18 Dec 2006
のメールが複数
送受信日時が　2007/01/18
として生成される

秀丸のMLでは
奇しくも「ごみ箱にごみの数」の話題のあたり
hidesoft.8:29547| RE 29543
～
hidesoft.8:29549| RE 29545
が該当します。

これらのメールが、適切な送受信日時を以て
一旦受信・生成され、その後おかしな増殖をしているのか、
それとも、当初から
送受信　2007/01/18
として生成されてきたのかはちょっと不明ですが、
ゴミ箱には、
送受信　2007/01/18
となったものしか残っていません
＃ゴミ箱のものと合わせて２つずつ生成されています

自分でもなんだかよくわからないので、
要領を得ない投稿かも知れません。よろしくお願いします。

RE:29844 メールが増殖？

秀まるお2 さん　07/01/12 14:01

　Date:ヘッダじゃなくて送受信日付が狂ってるのだとしたら、パソコンの内部
時計が狂ってるせいじゃないでしょうか。一回確認してみて欲しいてす。

　今現在受信するメールが正しい送受信日付/時刻になるのなら、今後は大丈夫
だと思いますけど。たまたま一時期おかしかっただけとか？。

RE:29851 メールが増殖？

hajimett さん　07/01/12 16:03

From: 秀まるお2--2007/01/12/Fri
Subject: hidesoft.8:29851| RE 29844 メールが増殖？
>　Date:ヘッダじゃなくて送受信日付が狂ってるのだとしたら、パソコンの内部
>時計が狂ってるせいじゃないでしょうか。一回確認してみて欲しいてす。

>　今現在受信するメールが正しい送受信日付/時刻になるのなら、今後は大丈夫
>だと思いますけど。たまたま一時期おかしかっただけとか？。

なるほど　ちょっと確認してみます
それで、複数生成されちゃうのも説明できますか

う～ん　でもなんか変だな。

RE:29855 メールが増殖？

秀まるお2 さん　07/01/12 17:35

　複数生成されちゃうのは説明出来ません。

　ハードディスクを検索して、その、2007/1/18のタイムスタンプのファイルが
他にもあるかどうか探してみるといいかもしれないですけど。

　あとはよく分からないです。

RE:29857 メールが増殖？

hajimett さん　07/01/13 11:28

>　複数生成されちゃうのは説明出来ません。

それなりにできちゃいました。
削除したり異動したりしたものが(最新の情報)、
同期の際に、
タイムスタンプのいたずらで
更新されないため、再び復活する(古い情報)。
というシナリオです。
＃詳細は未検証
ということで、とりあえず悪夢です。
同期の際に、情報が失われています。

たぶん、おかしなタイムスタンプになっても正常に運用できていたのが、
１月にはいり、
****200701.txt
っていう名前のファイルに正しい情報が保存され始めて
問題が露呈したのだと思います。

>　ハードディスクを検索して、その、2007/1/18のタイムスタンプのファイルが
>他にもあるかどうか探してみるといいかもしれないですけど。

秀丸メール関係のファイル以外には無かったです。
何があったのか、多分、本当に短い間
時計がおかしくなっていたのだと思います。

受信ログ200701.txt　タイムスタンプが未来
本来であれば、１月最初の情報が入っているはずですが、その情報がす
っぽり抜けてしまいました。
(もしかしたら、同期もとのPCに残っているかなと云う淡い期待を抱き
ながら)。
とりあえず、安全のために、
受信ログ200612_230.txt
と名前を変えました。
＃却ってまずかったらご指摘下さい。

タイムスタンプが未来なのは
あとは、複数生成の要因となった、受信したメールのファイルです。
****200701.txt
の他に、
****200612.txt
というのもあります。

前者は　時計がおかしかったときにできたファイル。
後者は　時計がおかしかったときに更新されたファイル。
なのでしょう。

どちらも、12/18あたりの情報が入っています。

あれ、でも、秀丸メールMLのファイルに
当該タイムスタンプのファイルがありません。
どうして、復活したんだろう。。
やはりすっきりとは説明できません。
受信ログには残っています(1/18に受信したとして)。

とりあえず、同期を一世代前に遡ることはできるので、
そこである程度修復しようと思っていますが、
それでは充分ではない場合もあり得ると思うので、
いくつか教えて下さい。

１）list.bin　について
これは、適宜矛盾があれば、更新されるものと理解しているので
ほっといてもよろしいでしょうか

２）もし、同期を一世代前に遡って
****200701.txt
をより新しい情報の入った変なタイムスタンプのファイルを
コピーすることで復旧できなかった場合、
12/18以降のメールを、再受信しようかと思っています。
「削除したらサーバも削除」という設定にしてあるので、
サーバには概ね残っています。
これを再受信するためには、どうしたらいいでしょう。
ある日以降の受信ログファイルをどっかに異動する、
って方法でしょうか。
送受新記録をどこかで切れば良いんですよね。

RE:29864 メールが増殖？

秀まるお2 さん　07/01/13 15:30

　状況がよくわかりませんが、とにかくその「同期」ってことをしたがために、
バックアップ用のファイルから勝手にリストアされてしまったってことですかね。
だとしたら、それはそれで手作業で復旧しつつ、今後はその「同期」の処理を考
え直した方がいいと思います。

　つまり、そういう、パソコンの内部時計が狂ったとしてもメール用ファイルが
おかしくならないように工夫することが必要だと思います。具体的にどうすれば
いいかはわかりませんけど。

　「同期」というか、単純にメールデータをバックアップするような動作をした
らいいと思いますけど。つまり、バックアップしたデータから勝手にリストアす
ることが無いように、その「同期」をやってるソフトか何かに指示してやればい
いんじゃないかと思います。

RE:29869 メールが増殖？

hajimett さん　07/01/13 17:36

>　状況がよくわかりませんが、とにかくその「同期」ってことをしたがために、
>バックアップ用のファイルから勝手にリストアされてしまったってことですかね。

えっと、二つのPCで仕事をしていて、
AのPCで仕事をしてメールデータが更新されたものを、
BのPCに移して(同期と呼んでいます)、しばらくBのPCで仕事して、
こんどはそれを、AのPCに情報を移して、しばらくAのPCで仕事して、、、
という運用です。

>だとしたら、それはそれで手作業で復旧しつつ、今後はその「同期」の処理を考
>え直した方がいいと思います。

タイムスタンプを見て、コピーする必要があるかどうかを判定して
という作業をしているのですが、タイムスタンプがずれると
その判定基準が間違っちゃう。
なので、本当は更新されているはずのファイルが、コピーされずに、
放置されちゃうので、一世代古くなった(のだと推測しています)。
私自身も事態の詳細は分からないのですが。。
とにかく、運用を改めないといけないと思います。

>　つまり、そういう、パソコンの内部時計が狂ったとしてもメール用ファイルが
>おかしくならないように工夫することが必要だと思います。具体的にどうすれば
>いいかはわかりませんけど。

はい。
とにかく、どうしたら最適なのかは追々考えるとして、
今どうしたらいいのかを解決したいです。
済みません。

>　「同期」というか、単純にメールデータをバックアップするような動作をした
>らいいと思いますけど。つまり、バックアップしたデータから勝手にリストアす
>ることが無いように、その「同期」をやってるソフトか何かに指示してやればい
>いんじゃないかと思います。

上述のように、タイムスタンプがずれていて、
より「新しい」ファイルが存在するので、上書きを回避ちゃったのだと
思います。（たぶんなんですけど）
そういう、変に気の利いた動作をする必要がない、
というかむしろそういうことをしないで、
冷徹に上書きや削除をするように設定しておくべきでした。

今考えているのは、HDに余裕がないとできませんが、
古いデータを別のディレクトリに回避し、
TuruKameDataのディレクトリを空にして、
それから、全体をコピーすれば、削除したものは削除された形で
異動するので、一番原始的だけど安全かなと思っています。
＃タイムスタンプが変化していないファイルは弄らない
　同期元から消失したファイルは同期先から削除する
　タイムスタンプが更新されたファイルはコピーする
　という運用だったのですが、「更新」が曲者でした。

で、どうも事態は単純じゃないようなので、
再度メールスプールにあるデータを取り込みたいので
再度メールスプールにあるデータを取り込む方法を
ご教示頂ければと思います。

RE:29871 メールが増殖？

アルビレオ さん　07/01/14 01:01

ユーザーのアルビレオです。

>えっと、二つのPCで仕事をしていて、
>AのPCで仕事をしてメールデータが更新されたものを、
>BのPCに移して(同期と呼んでいます)、しばらくBのPCで仕事して、
>こんどはそれを、AのPCに情報を移して、しばらくAのPCで仕事して、、、
>という運用です。

あくまで推測ですが、考えられそうなシナリオ

1.XとYという２台のPCで同期を取る
2.９日にXでメールA,Bを受信
3.１０日にYでメールA,B,C,Dを受信
4.ふたたび同期を取る

このとき通常なら最新の状態はYの方なので同期を取ることでX,Yの両方がA,B,C,
Dを受信した状態になり、矛盾は生じません。
ところが2.でメールA,Bを受信したときになぜか日付が１８日になっていると、
その後実際に１８日を過ぎるまでは同期を取るたびに2.の状態を「最新の状態」
と判断してしまうため、2.の「メールA,Bのみを受信した状態」に戻されてしま
います。

もしも起こっているのが上に書いたようなことであれば、「同期」ではなくYの
秀丸メールデータフォルダの内容をXに強制的に上書きすれば解消されると思い
ます。

もともと「ファイルの同期」というのは単純にタイムスタンプを比較して新しい
ものの方で古いものを上書きするといった程度なので、２台のPCでそれぞれ同じ
ファイルの内容を更新している場合はどちらかの更新内容を消してしまうことに
なるため危険です。
個人的には秀丸メールのデータフォルダはファイル同期の対象とせず、別々に
メールサーバから受信するようにしておいた方が安心できるのではないかと思い
ます。

RE:29873 メールが増殖？

hajimett さん　07/01/14 09:47

アルビレオさん
コメントありがとうございます

>あくまで推測ですが、考えられそうなシナリオ

同期という表現が曖昧でしたね。
かならず、もう一方のPCの電源を最初に入れたときに
最新の状態の情報に更新するようにしていたので
最新の情報にしていない状態で
もう一方のPCでメール受信することはしていません。
それをしちゃうと、
・メールをファイル単位で管理しているメーラ以外は
　メール情報がどんどん失われる
・メールリスト情報を保存したファイルと
　実際のメール情報とで矛盾を生じる
などすぐにおかしくなるからです。
ですので、以下のようなシナリオを想像しています

1.Xを基準にYの情報を更新する
2.９日にYでメールA,Bを受信　ここでタイムスタンプ事故発生
　→A,Bの受信日時が未来になる
3.１０日にYを基準にXの情報を更新する
4.XでメールC,Dを受信　Aを削除
　→この段階ではB,C,Dが保存されている
5.再びXを基準にYの情報を更新する
　この時、
　　・タイムスタンプが更新されたもの
　　・新たに作成されたもの
　　・削除されたもの
　だけを更新対象にしていたので、
　タイムスタンプ事故の生じた未来のファイルは
　タイムスタンプが同一のため更新がパスされる
6.Yでメールを開いたら
　未来に受信したAが復活
　(異動先のゴミ箱にもあるので増殖という印象)
　C,Dの情報が失われている
　ただし、この段階ではまだ、Xの中に
　C,Dの情報が入っているはず

このシナリオでは、
失われた情報も復活(増殖)したように見える情報も、
タイムスタンプがおかしくなったファイルに入っているはずなのですが、
どうもそういう単純な事態になっていないような気がします。
＃実際に、復活(増殖)した秀丸メールMLのメール情報が保存されている
　ファイルは正しいタイムスタンプのファイルに入っています。。
　受信ログの方は
　タイムスタンプのおかしなファイルに入っていましたが、
　何が起こったのだろう・・・？
　ここが、シナリオとしてすっきりしないところです。

　ああ。タイムスタンプがおかしくなったあと、
　まったく更新されなかったファイルだけが、タイムスタンプが
　おかしいままになるのですね。
　そうだとすると、今の段階でタイムスタンプがおかしいかどうかは
　手がかりとはならないですね。
　事故以後上記のシナリオを２往復しているので、
　もう、何が失われたかは藪の中です。

>もしも起こっているのが上に書いたようなことであれば、「同期」ではなくYの
>秀丸メールデータフォルダの内容をXに強制的に上書きすれば解消されると思い
>ます。

そうなんですよね。
そういう強制的上書きっていう操作って、結局
一旦先方の内容を完全に削除もしくは異動してから複写って
ことになりますよね。
フォルダやファイルが「削除」された事態への対応として、
同期ソフトが簡単だったので同期ソフトを使ってきました。
つまり、強制的上書きというのは、
・新規ファイルを複写
・新規フォルダを作成
・更新ファイルを上書
・消失ファイルを削除
・消失フォルダを削除
という操作をするのですが、
これなら、一旦、一方のPCの情報を空にして
＃異動するなどして
更地に全部移動すれば簡単なのですが、
その場合、HDDの容量が２倍必要になるのと、
時間が非常にかかるので、避けていたのですが、
とにかく運用を改める必要性を実感しました・

ＵＳＢメモリにTuruKameDataを入れて
二つのPCで付け替えて運用されている方は居ますかね。
これなら、単純にバックアップを毎週とるとかで、
対応可能かな。
なんとなく、信頼性に不安があるので避けていましたが、
こんな失敗がある方がずっと信頼性に欠けるので、
どうにかしないと。。

>個人的には秀丸メールのデータフォルダはファイル同期の対象とせず、別々に
>メールサーバから受信するようにしておいた方が安心できるのではないかと思い
>ます。

確かにこれが一番安心です。
ただ、これだと、削除したり整理したり
返信したりの痕跡が、統一的に管理できないので。。。

一応、最悪の事態を避けられるように、
受信した情報に関しては、あと２つ、
バックアップのアカウントがあるので、
その部分に関しては、良いのですが、
＃って　作業を考えると　あまり良くもないのですが
送信した情報が失われていたとしたら、
もう手に入りません(信用問題だな)。
＃自分宛Bcc:つける運用を復活させようかな

とりあえず、受信したメール情報だけは
確保したいので、
今考えているのは、
新たに秀丸メールで、ダミーアカウントを作成して、
同じメールサーバにアクセスしたら、
スプールの情報が取り出せるのかなと思っているのですが、
この考えは正しいでしょうか。
で、ダミーのフォルダを今のアカウントに作成して
そこに全部アカウント越えでコピーして、
一括振り分けして、重複メールの削除をすると、
手作業で整理した分以外は復活するかなと思っています。
この作戦は如何でしょう。

RE:29874 メールが増殖？

hajimett さん　07/01/16 10:08

自己レスです(あまり他の人には参考にならない情報？)

重要なのは受信ログ・送信ログ・各フォルダのメールファイルの
タイムスタンプなのですが、
デフォルトのまま、月単位で分割、２メガ越えたら分割にしています。

で、０６年１２月１８日に、０７年１月１８日になったという
事故が発生すると、この事故中に生成されたメールファイルの
「ファイル名」が、****200701.txtみたいになり、
タイムスタンプが０７年１月１８日になります。
事故が復旧したら、０６年１２月１８日の情報が入るべき
ファイルに追記していきます。
年が改まると、****200701.txtのファイルに新年からの
情報が追記されていきます。その時点で、タイムスタンプが
更新され、正しいものになります。

つまり、この、
「タイムスタンプ異常経歴を持つ」ファイルに入っていた
情報が失われるのですが、その特定が難しい。
受信ログは比較的簡単に問題を特定できるのですが、
各フォルダのメールファイルがなかなか動きが読めなくて。
ポイントは、
異動(振り分け)などの手作業を、事故中にしてしまったファイルです。
送受信時刻は本質ではありませんでした。

消失の原因となったファイルが、どんどん
更新されていくので、タイムスタンプ異常が消えてゆく。
原因の特定が難しい。

つまり、消えた(可能性のある)ファイルは、ある一定期間に
送受信したメール、というコトではなく、
「
事故中に振り分けたり異動したりという操作をしたフォルダで、
かつ年が改まってから操作が成されていないままだったフォルダは、
タイムスタンプ異常が保持されたまま別のＰＣに情報が移り、
そのあとその別のＰＣで、
そのフォルダ宛に振り分け異動なりで追記されたメール情報と
そのフォルダから削除異動なりで消去されたメール情報とが
もう一度もとのＰＣに情報を移した時に、
タイムスタンプ異常による上書き操作の不適切な回避のため、
前者は消失、後者は復活(増殖)する
」
というシナリオが一番事実に近そうです。

「ファイル名」が、****200701.txtのファイルを片端から
確認していくってのがもっとも堅実な方法でしょうが、
確認が面倒なので、復活は容認するとして消失はまずいので、
二つのＰＣに入っている
「ファイル名」が、****200701.txtのファイルを全部
マージしちゃうってのは許されるでしょうか？

>つまり、強制的上書きというのは、
>・新規ファイルを複写
>・新規フォルダを作成
>・更新ファイルを上書
>・消失ファイルを削除
>・消失フォルダを削除
>という操作をするのですが、
一番重要な事項を忘れていますね。
強制上書きの場合
・非更新ファイルも上書き
ですね。。

>新たに秀丸メールで、ダミーアカウントを作成して、
>同じメールサーバにアクセスしたら、
>スプールの情報が取り出せるのかなと思っているのですが、
>この考えは正しいでしょうか。
>で、ダミーのフォルダを今のアカウントに作成して
>そこに全部アカウント越えでコピーして、
>一括振り分けして、重複メールの削除をすると、
>手作業で整理した分以外は復活するかなと思っています。
>この作戦は如何でしょう。
ですが、失われた可能性のある情報の
やりとりされた期間が特定できないことが分かったので、
一応上記の操作はしましたが、
気付いていない消失ファイルがまだあるかも知れません。

皆さんもお気をつけください。
＃って、こんな粗忽は私だけかな

RE:29908 メールが増殖？

hajimett さん　07/01/16 11:42

済みません　秀まるお2さま
一点確認させて下さい

>「ファイル名」が、****200701.txtのファイルを片端から
>確認していくってのがもっとも堅実な方法でしょうが、
>確認が面倒なので、復活は容認するとして消失はまずいので、
>二つのＰＣに入っている
>「ファイル名」が、****200701.txtのファイルを全部
>マージしちゃうってのは許されるでしょうか？

と書きましたが、先の自分の投稿を見ると、
異常なタイムスタンプのファイルには、
****200701.txt　以外の末尾のものが含まれていました。
私の理解では、これは、
「削除」「マークづけ」「既読化」「異動(転出)」「振り分け(転出)」
などのメール本体自体の「追加」を伴わない操作を加えた場合に、
ファイル名を維持しながら、内容を書き換え、更新する、
という仕組みによると推定しています。
一方、「振り分け(転入)」「異動(転入)」「受信」などの
メール本体自体の追加が生じる場合は、PCの時計が月をまたがった場合
＃設定によって
たとえ既存のファイルにサイズ的余裕があっても
新しいファイルを生成する。
以上の理解で正しいでしょうか。

とりあえず、マークとかスレッド構造とかの改変、
削除したはずの復活は目をつむるとして、
消失だけは確実に復旧したいので、よろしくお願いします。
申し訳ありません。

RE:29912 メールが増殖？

秀まるお2 さん　07/01/16 12:40

> 一方、「振り分け(転入)」「異動(転入)」「受信」などの
> メール本体自体の追加が生じる場合は、PCの時計が月をまたがった場合
> ＃設定によって
> たとえ既存のファイルにサイズ的余裕があっても
> 新しいファイルを生成する。

　メール用ファイルの生成方法が「月単位に分割する」になっていたら、そうい
うことになると思います。