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

VERIFIED INVALID

Status

P2
normal
VERIFIED INVALID
21 years ago
10 years ago

People

(Reporter: davidh, Assigned: Bienvenu)

Tracking

Trunk
All
OSF/1

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

21 years ago
(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
(Reporter)

Comment 1

21 years ago
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.
(Reporter)

Comment 2

21 years ago
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

21 years ago
marking tvf 4.05 In and fixed

Comment 4

21 years ago
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

21 years ago
We could also put out a better error message.

Comment 6

21 years ago
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

21 years ago
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

21 years ago
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

21 years ago
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

21 years ago
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

21 years ago
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

21 years ago
moving to 5.0.

Updated

20 years ago
Assignee: delong → bienvenu
QA Contact: 4471 → 4098
Hardware: All

Comment 13

20 years ago
Will the new database address big endian/little endian issues?
(Assignee)

Comment 14

20 years ago
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

20 years ago
Great, if invalid in 5.0, then pls mark as such.  When we have something to
test, we will then mark this bug verified.
(Assignee)

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → INVALID
(Assignee)

Comment 16

20 years ago
OK, marking invalid.

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 17

20 years ago
Verified invalid.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.