2897 - can't delete mail messages (summary files big endian/little endian)

Status: VERIFIED INVALID

(MailNews Core :: Database, defect, P2)

Description

[davidh]

(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

Comment 1

[davidh]

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.

Comment 2

[davidh]

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.

Comment 3

[chris hofmann]

marking tvf 4.05 In and fixed

Comment 4

[sharoni]

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.

Comment 5

[sharoni]

We could also put out a better error message.

Comment 6

[dora]

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?

Comment 7

[sharoni]

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.

Comment 8

[edm]

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.

Comment 9

[chris hofmann]

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

Comment 10

[edm]

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.

Comment 11

[ksutton]

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?

Comment 12

[chris hofmann]

moving to 5.0.

Comment 13

[lchiang]

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

Comment 14

[David :Bienvenu]

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.

Comment 15

[lchiang]

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

Comment 16

[David :Bienvenu]

OK, marking invalid.

Comment 17

[scurtis]

Verified invalid.