>> It is that those users have Compress at exit checked for the >> Inboxes. When TB quits, sometimes the compressing is not finished >> until TB is shutdown by itself/Windows/user/not enough disk >> space/too little system resources etc. > In recent versions of The Bat! 3.99 (or some earlier) abortion > during compression is no problem, since The Bat! first writes to a > temporary file and then overwrites it using the atomic rename > operation. It’s not an application fault.
At restart, TB recognised the problem and offered the user to "repair" the problem. And messages were gone.... Sometimes I was able to get out some mail from those files, sometimes it was a 1 GB file full of zeros.. > The problem is that during a massive disk write operation How did you compress the folders: sequentially or parallel? (I never tested it.) > , file cache may not be fully flushed to the physical disk by the > OS. FAT32 is very vulnerable in such cases. I accept the last sentence :) > In future versions, we will make folder compression less frequent, > e.g. only when the amount of unused space have reached a certain > percent. That will just lower the chance of problems... Maybe a good idea would be to _allow_ (if he's got enough space) the user to have a backup copy of the message base, i.e. after compress you rename the tbb file to bbb, tbi to bbi, and the temp files to tbi and tbb. Just in case... I mean, really no offense (I make money from TB, so I am a shareholder :)), but I myself make a copy of the whole messagebase dir before I compress them... I dont want to lose email. -- Vili ________________________________________________________ Current beta is 4.0.0.22 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html
