(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #90509 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=90509 Imported into Bugzilla on 02/04/99 15:23) On DEC UNIX 4.0b, Communicator 4.04, Oct 13 build Trying to delete email message, I get a "communications exception (-456)" error msg. Clicking okay, the message remains in the in box. David x5275

I have not been able to reproduce this bug. I exited Communicator, went to another browser, went back to Communicator (4.04), and had no trouble deleting. I will keep an eye out to determine what is happening.

It seems that in order to re-produce this bug, you have to exit Communicator, re-start and send yourself a message. After receiving it, Communicator won't let you delete it. But if you restart Communicator, you'll be able to delete all old and new messages.

marking tvf 4.05 In and fixed

This is not fixed, but it should not hold the release. We should probably fix this in 5.0. edm and dora if you agree, please change the target fix version. OSF and other platforms are a different endianness. The summary files for mail are built differently depending on which endianess is used. Summary files built by other platforms are not useable by Communicator running on OSF, and vice versa. To recreate this problem, compress all folders on OSF. Exit Communicator. Start Communicator on another platform, like Solaris. Look at your Inbox. The summary file will be recreated. Try to delete a message. Solaris Communicator will choke when it tries to use the summary file of the Trash folder. It won't be able to delete messages. Solaris Communicator will appear to be broken. Either viewing the Trash folder, or compressing the folder will rebuild the summary file in the right format. You can delete messages. Exit the Solaris Communicator and go back to OSF. You will have the same problem in reverse. The summary file for the Trash will be in Solaris format and OSF will choke when it tries to delete mail. You have similar problems when you try to file mail into folders whose summary files have not been reformated. The work around is for the user to Compress All Folders immediately after switching from non-OSF Communicator to OSF Communicator, and vice versa (although from a DEC perspective it's hard to imagine anyone wanting to switch away from OSF Communicator) A good code solution might be to detect the incompatibility the first time a message is deleted or filed into a folder with an incompatible summary file. We could then rebuild the summary file and move or trash the message.

We could also put out a better error message.

This has been a known bug for 4.0. Last I recall, one cannot share the summary from OSF and other UNIX due to endian problem. I'd suggest to mark this bug 5.0 if we intend to fix the summary file problem in 5.0. Or, we should mark this bug as won't fix. edm, any suggestion?

I agree that we shouldn't spend the time making the summary files compatible. That's not really the core of the problem here. The problem is that the user gets an error message that doesn't give a clue about what's wrong. It doesn't say whether the message was deleted or not. It doesn't say whether the Inbox is corrupted, or the summary file is bad, or the delete action is broken. "Communication exception" sounds like the network is broken. Can we at least give the user a better error message? If we say that the summary file is looking funny, the user can think about it and do something to cause the summary file to be rebuilt.

Well, this strictly isn't a Nav 4.04 issue, it's a Communicator issue, as Sharoni stated to me. I attempted fixing the case where while user was on Digital UNIX, they saw this problem. I didn't even make an attempt to fix this for a situation where user switch between platforms using the same summary files. [ I believe my "fix" which involved a "bad" sscanf of a long into an int was creating two problems - unaligned access messages, and also this communications exceptions error message] In any case, we should look at this for future, not now. I would recommend taking this off the OEM 4.04 must be fixed list. The new message idea sounded pretty good, but I'm not interested in trying to either fix/have someone fix it to hold this Nav 4.04 OEM up.

Did someone come up with the new error message, and get L10n to approve? need to cut off changes for 4.05 very soon.

I didn't create a new error message. I've not looked into fixing/working around this for any 4.0x or 5.0 versions. But, to be safe, I marked this 4.06. I'd like to see this fixed in 5.0 eventually. However, for this release (4.05), I don't see the necessity of fixing this. We know there is a workaround. I've polled various people inside our Digital UNIX organization, and none appear too worried about this. Noone can give me an estimate of what the customer impact is. We don't know how many of our customers read mail in a multi-platform environment. Ed M.

Chris, After reading the comments on this bug it does not appear that it will be fixed for 4.06. Can this be marked for 5.0 or 6.0 to get it off of the 4.06 radar?

moving to 5.0.

Will the new database address big endian/little endian issues?

Yes, the MDB interface only talks about string properties - it's up to the client to convert this string to an internal numeric representation. Or, put another way, we store numbers as strings, which can be read by any endian type of client. This bug is invalid in 5.0.

Great, if invalid in 5.0, then pls mark as such. When we have something to test, we will then mark this bug verified.

OK, marking invalid.

Verified invalid.