The_Boojum wrote:restarted Thnderbird in case there was some other problem. Checked that the new version was in - it was. Did Quick Backups of all extensions - No problems.Then did Backup of all extensions and got the following messages in the Log:Timestamp: 11.05.2012 18:45:22Error: TEBE debug: tebeCopyFile(): Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsILocalFile.remove]Source File: chrome://tebe/content/tebeCommon.jsLine: 159

Thanks, you have trapped something useful there. The tebeCopyFile "errors" are actually normal insasmuch as they're not fatal. They're being reported now because of the additional error reporting I put in place. I still need to look at this because I don't think it should be complaining about normal copy operations that can't be completed because the file isn't present.

The last error is a problem because the variable tebeBuItemVerifiedList isn't defined and would be fatal I think. I don't know why it didn't happen for me, that's a bit of a mystery, however, I fixed that problem and I'm about to post another version for you to try. Investigating that also showed me that there were some related pieces from FEBE that I had missed and not ported, so I've added those now, too. The new code is related to extension verification and should be used when backing up and when using the Verify Extension Directory function on the Advanced tab.

The (f|t)ebeBuItemVerifiedList[key] is undefined error condition is usually fixed by running Clear (F|T)EBE preferences under the Advanced tab in the options window. The underlying cause of the error is still not addressed, but the fix is known.

clearing the prefs worked fine. As long as I do not back up the messages it now completes normally.

However if I add the messages to be backed up it writes only 2 files and does not issue the end report. The files are:profileTb{default}.tbu which is very big, as it should be, andResults - TEBE 2012 05-24 22.31.24.html which I cannot open.It appears that a) none of the extensions, address books or prefs were backed up, andb) none of the messages from other profiles were backed up, which I assume means that I have to run TEBE for each of my userids separately.There appeared to be no messages in the error log.Regards,Hugo

I had enabled the backup verification code and I think that it was causing problems. Everything seemed to be working quite well a few versions ago. I've now disabled it so we'll see how things change. I also fixed the copy error, which was caused by not checking that a file existed before trying to remove it. I'll post a new version in the usual place.

Fingers crossed.

Chuck, can you provide some input here? What is the status of that code in your eyes? It is somewhat of a mess, unfortunately, and it appears to me that it had been disabled because it had had issues somewhere along the line. There are multiple conflicting function and variable declarations related to this functionality so it really needs cleaning up or removing. Much of it is still active but the controlling pref is hard-coded to false to prevent it operating. I have a feeling there used to be an option for verification but that's no longer present either.

The_Boojum wrote:Now everything works fine except the Messages are not being backed up, the file - mailMessages{default}.tbu - is 0k. The "Chrome script timeout" is set to 0. There were no TEBE Debug messages in the Error Log. The TEBE Results Report says that the messages were backed up.

I'm unclear what you're saying as you seem to contradict yourself. Are the messages not backed up or is mailMessages{default}.tbu OK. How can it be both? Please clarify. Otherwise it sounds like things have improved, which is good.

spaceShot9 wrote:Chuck, can you provide some input here? What is the status of that code in your eyes? It is somewhat of a mess, unfortunately, and it appears to me that it had been disabled because it had had issues somewhere along the line. There are multiple conflicting function and variable declarations related to this functionality so it really needs cleaning up or removing. Much of it is still active but the controlling pref is hard-coded to false to prevent it operating. I have a feeling there used to be an option for verification but that's no longer present either.

Yes ... I was in the process of completely removing the validate backup code and must have gotten side-tracked. The function was not very helpful anyway. The only "validation" it performed was insuring that the backup file was indeed written to disk. Restore functionality and zip archive testing were my ultimate goals for that, but never got implemented. In retrospect, I believe the added functionality does not justify the added bloat. The only true test of a valid backup is simply to restore it and see if all is ok (even then it is only guaranteed valid at that particular moment - storage media goes bad, backup files get overwritten, etc.).

Gary,the report says that the messages have been backed up, but the file on the disk is empty - so the code is writing the entry in the report when it creates the backup file and not when the actual backup has been done. There is no backup data. In a previous version when I only selected the messages to be backed up it worked fine. In the latest version even this no longer works. At the moment there seems to be no way to back up the messages.Hugo

Gary,in asynch mode everything works fine. All extensions, prefs, address books, and messages backed up correctly.Schedule now set for daily processing.Many thanks for all your hard work to get this working.I am, and will remain, a fan of TEBE/FEBE.All the bestHugo

spaceShot9 wrote:Chuck, can you provide some input here? What is the status of that code in your eyes? It is somewhat of a mess, unfortunately, and it appears to me that it had been disabled because it had had issues somewhere along the line. There are multiple conflicting function and variable declarations related to this functionality so it really needs cleaning up or removing. Much of it is still active but the controlling pref is hard-coded to false to prevent it operating. I have a feeling there used to be an option for verification but that's no longer present either.

Yes ... I was in the process of completely removing the validate backup code and must have gotten side-tracked. The function was not very helpful anyway. The only "validation" it performed was insuring that the backup file was indeed written to disk. Restore functionality and zip archive testing were my ultimate goals for that, but never got implemented. In retrospect, I believe the added functionality does not justify the added bloat. The only true test of a valid backup is simply to restore it and see if all is ok (even then it is only guaranteed valid at that particular moment - storage media goes bad, backup files get overwritten, etc.).

Alrighty, thanks. I've disabled most of it already. In due course I'll step through and remove the remaining references.