I'm trying to help someone out who's Incredimail system has crashed (again) so I'm exporting all the emails and suggesting a less "fun" but slightly more robust system to import back into.

I just want to recommend looking at how they store things as an example of how not to do it!

I'm just working off the .imm files (which seem to be th email header & body) but there's also .imh and some SQLite databases and a Messages directory with a load of numerically named folders (1 to 6) each of which contain a load of GUID named folders which may or may not contain anything and if its folders they may or may not be empty. I'm sure it all made sense to those who designed it but WOW.

Roy Lambert

Roy Lambert wrote:

<snip>

I just want to recommend looking at how they store things as an example of how not to do it!

<snip>

Probably wasn't "designed" - just grew like topsy!

On 5/23/2018 10:19 AM, Roy Lambert wrote:
> I'm just working off the .imm files (which seem to be th email header & body) but there's also .imh and some SQLite databases and a Messages directory with a load of numerically named folders (1 to 6) each of which contain a load of GUID named folders which may or may not contain anything and if its folders they may or may not be empty. I'm sure it all made sense to those who designed it but WOW.

This is not unlike what outlook express (i think) did :

- sqlite database would likely be headers and subject and such used by
app itself to allow quick display and searching etc

- imm/imh files are actual emails as putting them in the sqlite would
have blown that one up likely  (outlook had eml i think).

Can't comment on folder structure but using guid for folder names is not
a bad idea from app aspect.

Raul

Raul wrote:

>  using guid for folder names is not a bad idea from app aspect.

It sort of fits with the "computer science" idea of hashed buckets too, but I'm not sure it would work well for long term use. On the other hand, a folder with "2018-05" would soon have people poking their noses in trying to be clever. So long as you can rebuild the core from the contents, it probably doesn't matter what you call the directories.

The one thing people don't need to learn is that a single directory with hundreds of thousands of emails is not a good idea. Do not do it! I had a little NAS once that I filled a directory with, and it was unable to cope. Even doing a delete would usually time out as it tried to operate on a file. Eventually I wiped the NAS as the only way to recover. Windows, oddly, coped a lot better, but even there I decided to use sub-directories.

Umm, this is a discussion of single file databases isn't it? 8-)

--

Matthew Jones

Matthew


>Umm, this is a discussion of single file databases isn't it? 8-)

Funny you should say that I did have the thought that it would be much easier to hide the steaming pile in a single file where it couldn't be seen. Then people like me would be totally stuffed instead of "inconvenienced"

Roy

Jeff


>Probably wasn't "designed" - just grew like topsy!

Nah. I bet it was designed using all the latest theories or at least the theories that were new c20 years ago

Roy

Raul


>This is not unlike what outlook express (i think) did :

OE was a paragon of cleanliness by comparison with IncrediMail

>- sqlite database would likely be headers and subject and such used by
>app itself to allow quick display and searching etc

Headers (sort of)  & lists of directories (I think)

>- imm/imh files are actual emails as putting them in the sqlite would
>have blown that one up likely (outlook had eml i think).

Yup OE used .eml and not much else its problem was it couldn't handle large amounts of data - the full DBISAM & ElevateDB & WPTools & embarcadero newsgroups I maintained in DBISAM wouldn't work - its why I rolled my own

The ,imm files seem to be emails the .iml files are something else - not sure what.

When IncrediMail bombs its usually the sqlite db that's corrupted the various mailboxes are ok(ish)

>Can't comment on folder structure

I can, but not in polite society!

Roy