[godelski]

  > are you being for real?

Yes

  > did you see anything as such in the bug listing?

Yes

  > but even IF they did put safeguards in place, the fact that this is SEVENTEEN YEARS, no warning, functionality still enabled without ANY WARNING losing people data. unforgivable.

The software has change a ton in 17 years. Right? We can agree on this? (I mean it underwent a major revision in 2018, getting a lot of the codebase rewritten (like Firefox Quantum).

So let's consider a hypothetical situation. Suppose the problem was resolved in the almost 2 decades of rewriting BUT you still do not know what caused the bug in the first place and, consequently, can't reproduce it.

Do you mark the bug as resolved?

Now let's not sit in the hypothetical setting and act as developers. Some safeguards have been put in place (you can verify by looking at referenced issues). You've solved similar, but are unable to determine if these are the same problems or different problems (again, see referenced or use the search).

Do you mark the bug as resolved?

Your sibling commenter implied they would. Personally, I wouldn't. Marking as resolved is a promise to the user that it is fixed. But I can't make such a promise. I can't make any strong statement until I can reproduce. So yeah, it seems appropriate to me that it is marked as "unresolved" with steps "needs reproduction." That is an entirely appropriate status to me. You try as hard as you can and you implement as many safety features as you can, but you don't mark as resolved until you can verify. Unfortunately, this means issues go stale. Hell, there'll even be some noise like if a hacker or even just your dog deleted everything. We wouldn't want to assume the user is dumb and lull ourselves into a false sense of security, right? But you can only do so much.

*YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG*. That's the policy they are using. You may use a different policy, but that's the one they are using.

[redeeman]

> YOU CANNOT CLOSE A BUG REPORT IF YOU CANNOT VERIFY THE BUG. That's the policy they are using. You may use a different policy, but that's the one they are using.

and then I would say: YOU DO NOT STOP WARNING PEOPLE UNLESS YOU CAN VERIFY ITS FIXED

(which ofc assume you bothered warning people to begin with)

[godelski]

  > UNLESS YOU CAN VERIFY ITS FIXED

Ummm...

Yes?

Aren't we saying the same thing then?

We must be talking past one another. I'm (and others) are assuming they can't reproduce the bug. Assuming they aren't lying when they say so and assuming they've tried.

I mean let's take the trivial case. Assume user is dumb, deleted the files, made a bug report. Devs will never be able to reproduce unless user tells them they deleted everything 'on purpose'. That ends up with a permanently opened bug report no matter how much time you spend trying to fix the issue and no matter how many safety features you build in, right?

[redeeman]

no, I am saying that I agree that you shouldnt mark it fixed until you know its fixed.

I am also saying that if they dont know for a fact its fixed, they should WARN PEOPLE IT MAY EAT DATA.

its 17 years!

[godelski]

Okay, then yes I misunderstood you. I mostly agree but it's also been 17 years and what are the odds that the offending code still exists? What are the odds that it's TB's fault?

I know people report the issue but googling I can find similar complaints across all major mail clients.

I just don't think there's enough information to make strong conclusions and I don't think California cancer warning labels work. I think they teach people to ignore warnings instead.