276942 - Second failed import attempt from OE destroys existing folders

Status: VERIFIED WORKSFORME

(MailNews Core :: Import, defect)

Description

[youcanprobably guess]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla Thunderbird version 1.0 (20041206)

Having successfully imported my own email from Outlook Express, I renamed the
new 'Outlook Express Email' folder that TBird created (to avoid a collision on
it) and tried to import my wife's email (mostly to get it into a more
readily-portable format) - but only changed OE's startup default rather than its
default identity to use for other programs.

TBird apparently tried to re-import my own email folders again but somehow got
confused by the fact that the default identity had changed.  The result was not
only an import failure (which wouldn't be worth reporting in itself) but
deletion of the mail files (though not their indexes) which it had just created
with the earlier successful import (even though they should have been isolated
from any visibility due to the change in the name of their parent directory - a
name change I had verifed by checking with Explorer).  It also had some
difficulty in cleaning up the new (useless) OE Email folder when I tried to (it
magically reappeared once outside the trashcan after having been banished there).

When I reimported my own stuff, reconfigured OE appropriately, and again renamed
the TBird directory, importing my wife's email worked fine.  So this bug is
clearly of pretty low priority, save that there's some code path in TBird that
gets not only seriously but destructively confused under some circumstances.


Reproducible: Didn't try

Comment 1

[Doug Wright]

Not a TB auto-migration bug -> Core:MailNews:Import

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[youcanprobably guess]

"Statistically, we have found that bug reports that have not been confirmed by a
second user after three months are highly unlikely to be the source of a fix to
the code."

In other words, you don't make any effort to try to reproduce obscure reported
bugs yourselves unless more than one person reports them.  And when the sole
reporter has already worked around the error to his or her own satisfaction,
there's of course hardly any incentive for them to put in additional effort when
you yourselves haven't put in *any*.

Hey, it's your software, and your quality (or lack thereof).  And since the free
version of Opera has become ad-free as well, anyone who isn't happy has another
very viable choice.  After all, this was a relatively obscure situation (though
with at least mildly alarming consequences), and nobody expects software to be
perfect:  just ask Microsoft.

My only real problem comes from your apparent belief that a bug can reasonably
be marked 'resolved' without any attempt to reproduce it having been made on
your part.  *That* borders upon sleazy, but I guess I can't expect to find the
same kind of work ethic that I enjoyed doing system software development at DEC
2 - 3 decades ago:  there just aren't many good examples to follow any more.

(Which does raise an interesting question, though:  do today's Linux kernel
people ever mark bugs resolved without having made any attempt to reproduce them?)

- bill

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Build Identifier: Mozilla Thunderbird version 1.0 (20041206)
> 
> Having successfully imported my own email from Outlook Express, I renamed the
> new 'Outlook Express Email' folder that TBird created (to avoid a collision on
> it) and tried to import my wife's email (mostly to get it into a more
> readily-portable format) - but only changed OE's startup default rather than
> its
> default identity to use for other programs...

David, do you know of any old backend bug related to renamed folders which would make comment 0 plausible?

nikoly, Przemyslaw, do you understand reporter's description?

Comment 5

[Przemyslaw Bialik]

Would be nice if reporter could try to reproduce the bug (e.g. with Thunderbird 2.0).
With 2.0 second import of mail from OE creates "Outlook Express Mail0" folder so even if 1.0 had some bug it's probably no point to debug it a few years later ;)
My reading is that was a mix with Bug 187734 and bug regarding renaming folder / importing into "Outlook Express Mail" folder which does not seem to be anymore.

Comment 6

[Wayne Mery (:wsmwk)]

reporter appears to be gone. probably WFM, but going with...
=> incomplete

Comment 7

[youcanprobably guess]

Reporter has not gone, just had nothing to add to his original comment, the gist of which was that marking a reported bug 'fixed' (or 'works for me', if that's what WFM means) without ever having made any attempt whatsoever to duplicate the reported situation to ascertain whether the reported problem may actually exist seems somewhat sleazy (but of course you can read the full version for yourselves right up there above).

I suspect that this bug-tracking system doesn't include a "Won't bother investigating" resolution option because it doesn't want to see bugs marked 'resolved' without having been investigated.  If that means that the bug just stays marked 'unconfirmed' and this is considered awkward, that's probably intentional as well.

- bill

Comment 8

[Nikolay Shopik]

version 2.0.0.17 (20080914) doesn't suffer from this problem

Comment 9

[youcanprobably guess]

While that's nice, it doesn't actually represent an attempt to reproduce the problem, just a quick attempt to avoid having to.

If the Tbird code base in this area has been redesigned and rewritten from scratch in the past four years, then there's a good chance that whatever problem used to exist may have been fixed; if not, then there's a good chance that the destructive code path is still in there somewhere, though perhaps now obscured by later changes such that (assuming that the other conditions that I described were faithfully duplicated) it no longer bites people in this specific case.

The way one makes sure is make an earnest attempt to duplicate the problem in Tbird V1.0, track down the offending code if that attempt succeeds (if not, *then* it would be reasonable to challenge me to substantiate it - and if so perhaps I'd actually try to get around to it before another four years have passed), and either ascertain that the misguided code is no longer present in the current version or fix it there - exactly the same steps that should have occurred four years ago if indeed the problem was considered 'critical' (your designation, not mine).

But as I said nearly four years ago, it's your software, and your quality.  I'm just trying to be a responsible user by providing applicable input, both to the bug itself and to the process which seems to be in place to handle it.

- bill

Comment 10

[Wayne Mery (:wsmwk)]

afaict Nikolay attempted to reproduce and couldn't.  I did as well, but I didn't state it at the time.  If anyone can prove this fails in 2.x or trunk then we can reopen.

Bill, status setting reflects the bug's status on *trunk/development*, not necessarily the reported version. And if you click "status" next to the status field you will see "All attempts at reproducing this bug were futile, ...".

v.worksforme

Comment 11

[youcanprobably guess]

While I appreciate the fact that after nearly four years someone finally started looking into this issue, I believe that I explained quite clearly above why what Nikolay did does not qualify as an "attempt to reproduce" it:  any legitimate attempt to reproduce a problem begins by using the software that exhibited it, and failure to reproduce it on newer software doesn't necessarily indicate that the problem no longer exists, only that it doesn't manifest itself in the way that it originally did.

Software quality is not attained by making annoying bug reports disappear:  it is attained by actually identifying and then if necessary fixing the underlying issue.  This ethic is difficult enough to achieve even with paid engineers (who in fact *are* often evaluated on their ability to get rid of bug reports in any nominally acceptable manner), so I sympathize with the even greater problem of motivating open source developers to embrace it.

But if your goal is real quality rather than just the facade of it, that's what you have to do.

- bill