受信添付の階層化No.41896
ほた さん 11/12/05 10:27
 
秀丸メールを仕事で便利に利用させてもらっています。

仕事で利用している関係で、現状、全メール数は14万通となっています。
それ自体はフォルダ分けしているので問題ないのですが、
受信添付のフォルダ配下に2万4千のフォルダが存在している状態で、
エクスプローラで表示しようとすると時間がかかります。

ひとつのフォルダ上に、大量のファイルやフォルダが階層化されずに
存在している状態は、ファイルシステム的にはあまりよくないとも
思っています。(これは昔の感覚なのでしょうか...)
受信添付を階層化できないかと秀丸メールの設定を見てみましたが、そのような設定
はなさそうでした。

受信添付フォルダ配下に「年月」(例:"201112")単位でフォルダを作成して、階層化
したいのですが、何かよい手はないでしょうか。

マクロなどでできるとよいですが、手動でフォルダを作成し、移動した上で、メール
を書き換えることで対応できるのでしょうか。
それが可能であれば、まずは手動で対応しようと思います。

#HTMLメールをよく利用する人は、受信HTMLが同様の状態になりそう
#ですが、特に影響はないのでしょうか。

[ ]
RE:41896 受信添付の階層化No.41898
秀まるお2 さん 11/12/05 13:19
 
 添付ファイル用のフォルダですか、普通だと、

 「受信添付\YYMMDD_nn」

 のようになります。ですが、実は

 「受信添付2\YYMMDD_nn」
 「受信添付3\YYMMDD_nn」

 のような形で「受信添付」フォルダを複数に分けるパターンは存在します。そ
うなる条件としては…

 実はハードディスクのフォーマット形式がFAT形式になっていると、1つの
フォルダの中に作成出来るファイル/フォルダ数に、だいたい3万個くらいって
制限が発生します。その制限が発生すると、上記のように「受信添付2」とかっ
て分ける風になります。

 NTFSの場合だと、いくらでもファイル/フォルダが作成出来るので、上記のよ
うな形にはならないです。

 ということで、とりあえず内部的な仕組みとしてそういうのがあるので、例え
ばNTFSファイルシステムの場合であってもフォルダ数がある程度以上になったら
上記のように分けるようにってことは可能だと思います。

 (そういうオプション類を追加すればの話になりますけども)

> マクロなどでできるとよいですが、手動でフォルダを作成し、移動した上で、メール
> を書き換えることで対応できるのでしょうか。

 上記のように「受信添付nn\YYMMDD_nn」風に分けることはマクロでなんとか出
来ると思います。

 一回トライして、後で書き込みさせていただきます。

> #HTMLメールをよく利用する人は、受信HTMLが同様の状態になりそう
> #ですが、特に影響はないのでしょうか。

 たしかにフォルダが大量に作成されてる人もおられるかと思いますが、普通の
ユーザー様はエクスプローラでその辺の一覧を表示させる必要は無いので、あま
り問題にはならないと思います。


 「ファイル・バックアップのお手伝い...」で古いメールを別アカウントに分
けると、結果としてフォルダ数も減らせるってのはあります。

[ ]
RE:41898 受信添付の階層化No.41900
秀まるお2 さん 11/12/05 15:37
 
 マクロでなんとかしようと思ったんですが、なかなか難しいです。

 マクロが間違ってしまうと添付ファイルがむちゃくちゃになりそうで、ちょっ
と怖いです。テストも大変そうだし…。(自分のメールがむちゃくちゃになるの
も困るし…)

 「受信添付」をなるべく分けるようにするオプションだけトライしてみようか
と思いますが…。果たして単純に「受信添付」が複数に分かれてればそれでいい
かという、そもそも根本的なことがよく分からないのに改良しても仕方がない気
もします。

 そもそも「受信添付」をエクスプローラで見る必要があるのは、何かの添付
ファイルを検索して探したいからなのかなぁと思うんですが、だとしたら、受信
添付が単純に複数に分かれていたとしても、検索にかかる時間は同じだし、あま
り意味が無いような気もします。

 現状で困ってることが、単純に「エクスプローラで受信添付フォルダを選択し
た時に待たされるのが困る」というだけで、それが解決出来ればいいってことな
ら、例えば手前味噌になりますが秀丸ファイラーClassicを使っていただくとか
って解決策もあったりするかもしれません。

[ ]
RE:41900 受信添付の階層化No.41901
秀まるお2 さん 11/12/05 15:58
 
>  「受信添付」をなるべく分けるようにするオプションだけトライしてみようか
> と思いますが…。

 最初に提案いただいたのに近い仕様でトライしてみます。

 「受信添付」に年の2桁だけ入れるか、または年と月の4桁数字を入れる作戦
でトライしてみます。

[ ]
RE:41901 受信添付の階層化No.41902
nito3 さん 11/12/05 16:27
 
> 「受信添付」に年の2桁だけ入れるか、または年と月の4桁数字を入れる作戦
>でトライしてみます。

横から済みません。
nito3といいます。
自分も受信添付の中に大量のフォルダ、ファイルを何とかしたくて、
とりあえず年毎の管理になるように「受信添付YYYY」を作成移動する
マクロを作っていただきました。(hidesoft.8:41267辺り)

このオプションを楽しみにしてます。

[ ]
RE:41902 受信添付の階層化No.41903
秀まるお2 さん 11/12/05 17:10
 
 これはこれは情報ありがとうございます。実は以前同じマクロを作っていたと
は知らず、また同じような物を作ろうとしてしまいました。

当時の発言の過去ログ:
  http://hidemaruo.dip.jp:81/hidesoft/hidesoft_8/x41261.html


 ということで、とりあえず当時作成したマクロを使っていただくことで、分類
出来るようです。ただ、14万通も処理したら、何時間、あるいは何日もかかっ
てしまうかもしれません。


 オプションの方はとりあえず追加出来て、一応、添付ファイルの生成もうまく
いくことは確認出来ました。しばらくテスト運用してからV5.72β22として公開
させていただきます。

[ ]
RE:41903 受信添付の階層化No.41905
ほた さん 11/12/05 22:02
 
あっという間に、実装されるところまで行っていてビックリしました。

>実はハードディスクのフォーマット形式がFAT形式になっていると、1つの
>フォルダの中に作成出来るファイル/フォルダ数に、だいたい3万個くらいって
>制限が発生します。その制限が発生すると、上記のように「受信添付2」とかっ
>て分ける風になります。
>
> NTFSの場合だと、いくらでもファイル/フォルダが作成出来るので、上記のよ
>うな形にはならないです。

私が気にしていたのは、FATのときの制限がなんとなく記憶に残っていたこと
によるもののようですね。NTFSでは制限がないのであれば、あまり気にしなくても
よいのかもしれません。

>「ファイル・バックアップのお手伝い...」で古いメールを別アカウントに分
>けると、結果としてフォルダ数も減らせるってのはあります。

別アカウントに分けることは現状でやっています。但し、「ファイル・バックアップ
のお手伝い...」は知りませんでしたので手作業でアカウント間の移動をしていました。

「ファイル・バックアップのお手伝い...」も便利そうですね。覚えておきます。

>現状で困ってることが、単純に「エクスプローラで受信添付フォルダを選択し
>た時に待たされるのが困る」というだけで、それが解決出来ればいいってことな
>ら、例えば手前味噌になりますが秀丸ファイラーClassicを使っていただくとか
>って解決策もあったりするかもしれません。

古いメールの添付ファイルを今後定期的に削除しようと思い、受信添付配下の
フォルダ毎、削除するのがよいかと考えています。

なので、秀丸ファイラーClassicがエクスプローラよりも早くて使いやすいので
あれば、確かにそれでよさそうです。(笑)使ってみます。

>「受信添付」をなるべく分けるようにするオプションだけトライしてみようか
>と思いますが…。果たして単純に「受信添付」が複数に分かれてればそれでいい
>かという、そもそも根本的なことがよく分からないのに改良しても仕方がない気
>もします。

想定していたのは、以下のような感じで「受信添付」の配下に
年月「YYMM」や年「YY」などでフォルダが作成されて、その下に現状の
フォルダ「YYMMDD_nn」が作成されるようなフォルダ構成です。

「受信添付\YYMM\YYMMDD_nn」

以下のような構成でも、年単位くらいで分ければちょうどよさそうです。

「受信添付2\YYMMDD_nn」
「受信添付3\YYMMDD_nn」

[ ]
RE:41905 受信添付の階層化No.41910
秀まるお2 さん 11/12/06 13:51
 
 添付ファイル/HTMLメールのフォルダ階層を

 受信添付\nn\YYMMDD_nn

 のように1段階増やすことは、互換性の維持の面で無理があります。

 なので、手元のバージョンで既に実装した、

 受信添付YY\YYMMDD_nn

 または

 受信添付YYDD\YYMMDD_nn

 のタイプにだけ出来るようにオプション追加します。「全般的な設定・上級者
向け・その他・その他3」に追加します。

[ ]
RE:41910 受信添付の階層化No.41924
ほた さん 11/12/08 00:52
 
> 添付ファイル/HTMLメールのフォルダ階層を
>
> 受信添付\nn\YYMMDD_nn
>
> のように1段階増やすことは、互換性の維持の面で無理があります。

了解しました。
階層を1段階増やすのが必須というわけではないです。

> なので、手元のバージョンで既に実装した、
>
> 受信添付YY\YYMMDD_nn

上記のパターンで利用しようと思います。

ちなみに「受信添付YY」の年は受信した日付の年でしょうか。

また、現状で受信済みのメールの添付ファイルについて
「受信添付YY」の形式に変更する(移行する)ことは可能でしょうか。

提示いただいているマクロで、移行することになるのでしょうか。

ご回答いただければ幸いです。

[ ]
RE:41924 受信添付の階層化No.41926
秀まるお2 さん 11/12/08 08:56
 
> ちなみに「受信添付YY」の年は受信した日付の年でしょうか。

 受信した日時の年になるので、例えば今日受信したメールは、メールのDate:
ヘッダが去年になっていようが、「受信添付11」になります。

 あと、年号だけじゃなくて月も入れて、「受信添付1112」のようにする
オプションも追加します。

> また、現状で受信済みのメールの添付ファイルについて
> 「受信添付YY」の形式に変更する(移行する)ことは可能でしょうか。

 一度別アカウントに移動してから元のアカウントに戻しててやれば、その
メールの添付ファイルについては「受信添付11」の新しいフォルダ配下に移動し
ます。

 去年受信したメールについては「受信添付10」に移動させたいとなると、それ
は現状の(手元のβ版では)無理ですが…。

 しいて既存のメールも分類したいとなると、あえてパソコンの時刻を変更して
移動させるか、または秀丸メール側で、メールの送受信日時に「受信添付XX」の
年号/月を連動させる動作にするかって作戦になります。それはそれでやろうと
思えば出来そうです。

 はてどうしましょ?

 一応、メールの送受信日時に連動させるパターンで対応出来るかどうかトライ
してみます。

[ ]
RE:41926 受信添付の階層化No.41928
秀まるお2 さん 11/12/08 09:57
 
>  一応、メールの送受信日時に連動させるパターンで対応出来るかどうかトライ
> してみます。

 受信/インポートについてはその日付固定にしますが、アカウントをまたがっ
てメールを移動/コピーした時については、メールの送受信日時を使って「受信
添付YYMM」のYYMM部分を決めるようにしてみました。処理的にも簡単に済んだの
で、この処理を次のβ版に入れてしまうことにします。


[ ]
RE:41910 受信添付の階層化No.41933
Iranoan さん 11/12/08 23:14
 
 秀まるおさん今日は、一ユーザの Iranoan です。
>  受信添付\nn\YYMMDD_nn
>
>  のように1段階増やすことは、互換性の維持の面で無理があります。
 この仕様のせいでしょうか、
>  受信添付YY\YYMMDD_nn
>
>  または
>
>  受信添付YYDD\YYMMDD_nn
>
>  のタイプにだけ出来るようにオプション追加します。
で使ってみたのですが、該当する全てのメール自体を削除しても、フォルダが
残ります。
 count.bin を見て 0 になった時点で、フォルダを削除したほうが良くない
ですかね。

[ ]
RE:41933 受信添付の階層化No.41935
秀まるお2 さん 11/12/09 09:19
 
 メールを削除(または別アカウントへ移動)することによって、「受信添付」
とか「受信添付YY」とか「受信添付YYMM」のフォルダ配下に添付ファイル用の
フォルダが無くなったとしても、その「受信添付」とかのフォルダ自体はそのま
ま残ります。

 特に削除する処理は作ってないし、削除するのはちょっと技術的にも難しいと
いうか、いちいち「空かどうか」ってチェックしないといけないので遅くなると
思います。

 count.binファイルは、単純に「YYMMDD_nn」のnn部分の番号を計算する用に覚
えているファイルでして、添付ファイル用フォルダの総数とかは全然覚えてない
です。

[ ]
RE:41935 受信添付の階層化No.41936
Iranoan さん 11/12/09 13:43
 
 秀まるおさん今日は、一ユーザの Iranoan です。
>  特に削除する処理は作ってないし、削除するのはちょっと技術的にも難しいと
> いうか、いちいち「空かどうか」ってチェックしないといけないので遅くなると
> 思います。
 解りました。

[ ]