23/12/03 chris : >you can almost be assured that when you do a >rebuild, there will be some house cleaning to be done afterwards to >redelete resurrected emails, or refile ones that have moved themselves.
And use the "normal" rebuild first, keep the advanced one as a desperate measure. For me the normal rebuild has always been painless (maybe a few resurrected messages to trash), but the advanced one made a mess of my filing the only time I tried. Fortunately Emailer keeps the old DB so I just had to trash the new files and rename the old ones. >First verify that the files are correctly named. Should be "Mail >Database" and "Mail Index". Unless you're using a non-english version of Emailer. I don't know if there was a UK-English one. French names of those files: Base courrier Index courrier >doubt, remove the Index file entirely and let Emailer build a brand new >one. I would also remove Emailer's prefs file from its current location (but keep it in case it's not the culprit). Just to make sure pref corruption isn't causing a problem. Emailer will ask for your Emailer files folder, make sure you select the right one (the folder containing the mail DB folder and many other things, not the mail DB folder itself). Emailer prefs should be either in the Claris folder in the active system folder, or the Preferences folder in the active system folder, or the same folder as the Emailer application (I'm not sure of the other 2, I've kept mine in the app's folder for so long I've forgot where it was before). >>Due to space limitations, I foolishly failed to back up my Mail Database. Did you also trash the backup version of the mail DB made during the rebuild? Emailer made new files and renamed the previous ones (probably adding " (old)" as a suffix). If you didn't trash those you can rename the new files with "(new)" for example and remove " (old)" from the old ones so that Emailer will use them next time, which should take you back to the state before the rebuild. >Make sure you have enough space for a new index file. Too bad Emailer doesn't do a "preflight" before rebuild to limit that risk. I found it to be very good at handling low-space situations in other circumstances (totally full disks never caused me the slightest problem during normal use: Emailer just complains it can't unpack a message because the disk is full; just free a few KB to return to normal, without quitting Emailer nor losing a single message). Of course it's never a good idea to run anything critical on full disks. Keep in mind that your Emailer files folder can be anywhere and have any name: if the volume where it is now is full, you can just copy it to another disk and tell Emailer where it is by holding F5 next time you launch Emailer. You can even put it on a server if you wish (I'm writing this on my Powermac 9600, but the DB is on my iBook, and I even launched the Emailer application that resides on the iBook to avoid having 2 preferences files -- that's one of the reasons why I keep the prefs in the app's folder). On 100BT Ethernet I don't even feel any lag during launch time or normal use, maybe only for things involving lots of messages at once like searching (but searching has always been slow in Emailer anyway). >And I bet next time your priorities on space will be radically different. 280 MB ... who doesn't have access to a CD burner nowadays? >Don't forget that a REALLY easy way to backup your mail database is to >simply stuff the entire Mail folder (database and index... always keep >them as a matched pair). I prefer to backup the entire Emailer files folder: the other files are very small compared to the DB anyway. This allows access to older versions of the addressbook, mail actions, scripts, accounts, etc. My preferred archive format is DiskCopy's compressed disk images, using DiskCopy from Apple (free) or ShrinkWrap (shareware). DiskCopy disk images made under OS 9 aren't as tightly compressed as stuffit or zip archives and have a resource fork so they can't be stored on non-mac platforms without .bin or .hqx encoding, but they can be used as is: there's no need to decompress an archive to use the content, which saves a lot of time and space. ShrinkWrap can also use the StuffIt Engine to achieve compression levels on par with stuffit archives, but those disk images can't be mounted under OS X, even though Aladdin bought ShrinkWrap and included disk images support in OS 9 versions of StuffIt Expander. I store all my dictionaries and encyclopedias that way and made a script to automatically mount disk images and launch the related application. This avoids installing tons of files and wasting a lot of space, and makes transfers and backups much easier and faster. ---- VRic ___________________________________________________________________________ To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
