I probably just couldn't see the wood for the trees.(Warum nicht gleich so....)
Yes, that's the underlying problem. In contrast to "real" archives such as ZIP, mbox files do not contain file names, so the plugin must create them itself.I understand that the naming of files is an internal necessity of the mbox format
Are those mails with numbers (1) and (2) sometimes identical, or are they always different?which are 33 mbs files, I find in every second file some mails with numbers (1) and (2)
I think there are 2 things to consider:
a) How to give almost all mails a unique filename, with as few exceptions as possible.
b) What to do in case of an exception (naming conflict).
ad a)
As you know, the plugin currently creates the filename from the subject of the mail, and then appends '_' and a hexadecimal number with 9 digits – representing date, time and time zone of the mail – to it. To be correct, not the complete information is used. mbox only uses one hexadecimal digit for representing the time zone, although there are AFAIK 24 different time zones. However, e.g. dbxplug.wcx - which allows TC to treat Outlook Express mail storage files as archives, and therefore has to solve the same general problem - only appends 6 digits to the subject in order to build the name. I actually was expecting that users would tell me that 9 digits are too much and too "ugly". But nobody has complained so far.
In the past, someone had suggested to append the Message-Id of the mail to the name. If it was created correctly, this Id is unique in the whole world. I decided not to use the Message-Id, because sometimes it can be rather long, often enough mails don't have a Message-Id at all, and also I want, when TC lists the mails inside an mbox sorted ascending by name, that it is guaranteed that older mails show up in the list before newer mails with the same name. So I have to use a number that has something got to do with the date and time of the mail.
Maybe I could additionally use a checksum. Probably not the MD5 checksum, which is very good, but rather long ( e.g. 4e73a5e2becd12f1154049d6d21c1ff8
). A CRC32 checksum looks like this: 161A28EC. With such a checksum added, there would be 17 "cryptic" digits in the name ... Also, firstly I would have to test how long it takes to calculate the checksum. Enough about this point for the moment. ad b)
I have an idea how to avoid the problem that your test above had shown. It would be easy to change the naming system, so that in case of duplicate names the name of the first mail is not changed, i.e. (1) will is not be appended. Then in your test, after deleting 1 mail in one mbox, TC would correctly only mark 1 mail as different. The disadvantage is, that this would cause inconsistent sorting of the mails (regardless whether in 'wincmd.ini' SortUpper is 0 or 1). The list of files from your test, sorted ascending by name, would look like this:
Code: Select all
aon.962051920_2A3770DA1(2) eml
aon.962051920_2A3770DA1 eml
aon.962051920_2A377CB71(2) eml
aon.962051920_2A377CB71 eml
aon.962051920_2A3A90591(2) eml
aon.962051920_2A3A90591 emlRegards,
Juergen
