〔A〕全部チェックしてある場合の、prefs.jsの設定。 設定エディターでは、「user set」になっている。 【チェックあり】 ダウンロード後もサーバにメッセージを残す mail.server.server#.leave_on_server = true 【チェックあり】 ダウンロードしてから14日以上経過したメッセージは削除する mail.server.server#.delete_by_age_from_server = true mail.server.server#.num_days_to_leave_on_server = 14 【チェックあり】 ダウンロードしたメッセージを削除したらサーバからも削除する mail.server.server#.delete_mail_left_on_server = true
〔B〕おっしゃっている設定の場合の、prefs.jsの設定。 【チェックあり】 ダウンロード後もサーバにメッセージを残す mail.server.server#.leave_on_server = true 【チェックなし】 ダウンロードしてから14日以上経過したメッセージは削除する mail.server.server#.delete_by_age_from_server = false => 内部的なデフォールトはfalseなので、このエントリーはなくなる Thunderbirdだと、設定エディターで、エントリーが表示されない SeaMonkeyだと、about:configで「default false」 mail.server.server#.num_days_to_leave_on_server = 14 【チェックなし】 ダウンロードしたメッセージを削除したらサーバからも削除する mail.server.server#.delete_mail_left_on_server = false => 内部的なデフォールトはfalseなので、このエントリーはなくなる Thunderbirdだと、設定エディターで、エントリーが表示されない SeaMonkeyだと、about:configで「default false」
で、おっしゃっている現象は、 (1) 〔B〕 に設定直後は、問題なく動作していたのだが、 (2) しかし、ふと気が付くと上記3項目がすべて【チェックあり】の、〔A〕になっていた。
この「〔B〕に設定直後」と「ふと気が付くと」の間に、何をなさいましたか?
上記の設定は、設定変更を行った時点でprefs.jsに書かれ、 Thunderbirdの起動中は、メモリー上に保存されている設定により動き、 Thunderbirdの終了時に最終的にprefs.jsに書かれ、 Thunderbirdの再起動時に、prefs.jsから読み込まれます。 従って、以下のような場合には、Thunderbirdの再起動後に〔A〕に戻っても当然になります。 - user.jsに〔A〕の設定が書いてある - 〔A〕の設定が書いてあるprefs.jsのバックアップで、prefs.jsを上書き - Thunderbirdのprefs.jsへの書き込みを阻害しているので、〔B〕の設定をprefs.jsに書けない
〔B〕に設定した後、〔B〕の設定がprefs.jsにきちんと書き込まれていましたか?
ちょっと気になるのは、デフォールトの変更の影響。 prefs.jsに設定が書かれていない時に、デフォールト=trueだったバージョンのThunderbirdと、デフォールト=falseに変わったバージョンのThunderbirdとで、同じprefs.jsを使いまわせば、〔A〕になったり〔B〕になったりします。 こういったことはしていないですか?
たとえ、Thunderbirdの問題で設定がリセットされてしまった、という可能性が十分にあっても、 上記のような、設定が意図通りにきちんと反映されていなかった、というようなことを、きっちりと除外しておかないと、 あれこれ調べてみても、無駄足を踏むだけです。
〔A〕全部チェックしてある場合の、prefs.jsの設定。 設定エディターでは、「user set」になっている。 【チェックあり】 ダウンロード後もサーバにメッセージを残す mail.server.server#.leave_on_server = true 【チェックあり】 ダウンロードしてから14日以上経過したメッセージは削除する mail.server.server#.delete_by_age_from_server = true mail.server.server#.num_days_to_leave_on_server = 14 【チェックあり】 ダウンロードしたメッセージを削除したらサーバからも削除する mail.server.server#.delete_mail_left_on_server = true
〔B〕おっしゃっている設定の場合の、prefs.jsの設定。 【チェックあり】 ダウンロード後もサーバにメッセージを残す mail.server.server#.leave_on_server = true 【チェックなし】 ダウンロードしてから14日以上経過したメッセージは削除する mail.server.server#.delete_by_age_from_server = false => 内部的なデフォールトはfalseなので、このエントリーはなくなる Thunderbirdだと、設定エディターで、エントリーが表示されない SeaMonkeyだと、about:configで「default false」 mail.server.server#.num_days_to_leave_on_server = 14 【チェックなし】 ダウンロードしたメッセージを削除したらサーバからも削除する mail.server.server#.delete_mail_left_on_server = false => 内部的なデフォールトはfalseなので、このエントリーはなくなる Thunderbirdだと、設定エディターで、エントリーが表示されない SeaMonkeyだと、about:configで「default false」
で、おっしゃっている現象は、 (1) 〔B〕 に設定直後は、問題なく動作していたのだが、 (2) しかし、ふと気が付くと上記3項目がすべて【チェックあり】の、〔A〕になっていた。
この「〔B〕に設定直後」と「ふと気が付くと」の間に、何をなさいましたか?
上記の設定は、設定変更を行った時点でprefs.jsに書かれ、 Thunderbirdの起動中は、メモリー上に保存されている設定により動き、 Thunderbirdの終了時に最終的にprefs.jsに書かれ、 Thunderbirdの再起動時に、prefs.jsから読み込まれます。 従って、以下のような場合には、Thunderbirdの再起動後に〔A〕に戻っても当然になります。 - user.jsに〔A〕の設定が書いてある - 〔A〕の設定が書いてあるprefs.jsのバックアップで、prefs.jsを上書き - Thunderbirdのprefs.jsへの書き込みを阻害しているので、〔B〕の設定をprefs.jsに書けない
〔B〕に設定した後、〔B〕の設定がprefs.jsにきちんと書き込まれていましたか?
ちょっと気になるのは、デフォールトの変更の影響。 prefs.jsに設定が書かれていない時に、デフォールト=trueだったバージョンのThunderbirdと、デフォールト=falseに変わったバージョンのThunderbirdとで、同じprefs.jsを使いまわせば、〔A〕になったり〔B〕になったりします。 こういったことはしていないですか?
たとえ、Thunderbirdの問題で設定がリセットされてしまった、という可能性が十分にあっても、 上記のような、設定が意図通りにきちんと反映されていなかった、というようなことを、きっちりと除外しておかないと、 あれこれ調べてみても、無駄足を踏むだけです。
|