Closed
Bug 789754
Opened 12 years ago
Closed 12 years ago
Do not remove message folder file and .msf file before moving temporary file
Categories
(MailNews Core :: Backend, defect)
MailNews Core
Backend
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 674742
People
(Reporter: hiro, Assigned: standard8)
References
Details
(Keywords: dataloss)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
To step forward to fix that bug splitting from bug 674742.
I'd propose to fix the issue of removal original folder first.
Attachment #659534 -
Flags: review?(mbanner)
Reporter | ||
Updated•12 years ago
|
Blocks: destroys_encrypted
Is this a joke? How many bugs can you "split"?
This is a duplicate of bug 674742. So, please keep it there.
Otherwise I would also "split" the bug a few times.
Why not you just commit my patch?
Why invent something else to do?
No longer blocks: destroys_encrypted
Depends on: destroys_encrypted
Wayne, isn't it your obligation to prevent creation of duplicate reports?
You should mark it so, and close it.
Instead, you decorate it with attributes, as if this report was legitimate.
You keep breaking the rules. Yet you ask me to keep to them, even when they do not apply.
Please spend your energy on bug 674742. There's something urgent to do.
I am sure you can at least post warnings on web sites. Especially on the one, which you yourself provided a link to.
Comment 3•12 years ago
|
||
No it is not my obligation to do as you suggest. On the contrAry you are both welcome to ask for reviews in the respective bugs. The reviewers and module owners or their proxy will ultimately determine what gets approved and checked in.
Reporter | ||
Updated•12 years ago
|
Summary: Do not remove message folder file before moving temporary file → Do not remove message folder file and .msf file before moving temporary file
Andrew, the bug 674742 is already too long to understand.
Hiro tries to split the work a bit to ease integration of the fixes. Smaller patches are better to review.
Please do not fight him, he tries to help the cause.
Assignee: nobody → hiikezoe
Status: NEW → ASSIGNED
But hiro, you propably should have posted to bug 674742 what are you splitting out from there. There is not explanation in that bug.
Reporter | ||
Comment 6•12 years ago
|
||
I supposed I did it in bug 674742 c#91 and c#110, but yes, I should have done it again clearly. That bug is too long and fast to follow up.
Oh, comment 91 is good, but does not contain reference to this bug number. But I also missed it as the bug is too long :)
(:aceman #4)
> the bug 674742 is already too long to understand.
Ludicrous! You complain not about the lack of discussion, but about the presence of discussion.
According to you it is better if bug reports were empty. Then you don't have to work at all.
Hiroyuki buries the discussion even in more useless comments, like bug 674742#c110, bug 674742#c122.
Other "participants" do not read much. Yet they do comment. They force repetition. Then complain that the bug is long.
Notice that nobody in bug 674742 counter argued me. My arguments are still valid. For example the argument that you should not destroy the compact copy on failure to rename it, because you have to give that choice to a user.
Mark in bug 674742#c118 ignored this argument, or perhaps never read it, although it was in review to patches, not lost among other text. He simply repeated the view by someone else, which I already successfully countered: that he "believes" in not leaving the temporary files behind.
He ignored my argument that the compact copy is no longer temporary. It is a valid file.
He wrongly suggested that Kent does not approve my patch. But in bug 674742#c79 Kent wrote the opposite: that he actually agrees with me, that leaving the compact files would be a "heroic" option.
The only thing Kent that failed was to put a review mark to approve my patch, or part of it. He failed to conclude.
Hiroyuki created a duplicate. Thus he forces repetition again.
Then you will complain that this bug is too long too. And create another duplicate.
What would you say, if I create one more duplicate? If anyone comments there, I would claim that the bug is too long, and discard them by creating another duplicate.
I would keep comments I like. If I do not like some, I would discard them again with a new duplicate.
Bug 674742 report is a discussion. Without it you would not understand that retaining the lines, which remove the compact and valid copy of mail folder is bad. Hiroyuki's patch is bad.
That is why he split it from bug 674742. To avoid discussion.
Bug 674742 report is long because too many "long-term" Bugzillians write too much useless stuff.
That is how my discovery of the cause is in comment #23, rather than in comment #5.
Lets write useless comments in this bug report too.
Hiroyuki created the duplicate not because he did not know of the original, but because he wanted a duplicate.
He explains the bad motive himself: the bug is too long. This means he does not want users, and programmers to read it.
"long-term" Bugzillians help him with that.
But he never makes his own report clear. He does not bring here relevant comments from bug 674742. He simply discards them.
He avoid discussion. That is why this duplicate.
> Hiro tries to split the work a bit to ease integration of the fixes.
What has become easier?
His patch was already separate and well seen in bug 674742.
Now it is separate from the discussion. He discarded a review about it.
What's worse: he wastes his own energy.
Let alone mine.
> Smaller patches are better to review.
He did not make his patch smaller.
he simply duplicated it, and got rid of its reviews, and discussions.
He only want to push his own patch without regard to consequences, and discussions. Perhaps he wants to earn some formal grade: maybe the sheer number of committed patches determine his promotion in Bugzilla.
But he fails to understand that he does not have to push his bad patch. He can push just any patch to earn the same promotion. Why not push a patch on my behalf?
> Please do not fight him, he tries to help the cause.
I try to utilise his energy.
He tries to waste it.
Everyone else - too.
(In reply to Wayne Mery (:wsmwk) from comment #3)
> No it is not my obligation to do as you suggest.
Surprise! Have you read Bugzilla?
Before adding a report it suggests to check for a duplicate.
A bug report can be only one. Read your own rules. Duplicates have to be closed, and marked so.
> both welcome to ask for reviews
A "duplicate" is not the same as a "review".
You deliberately substitute the terms.
You seem to suggest that bugs are solely the concern of reporters.
The entire Bugzilla has to rush to solve them. Especially the critical ones.
You too should ask for reviews. Don't put all the burden on me.
Why don't you publish the warning on the web site, which you yourself have linked in URL of bug 674742?
You are a member of that site. Yet you chose to "sit on a fence". Let more users fall victim to this bug.
Instead you would rather play with decorations, and useless comments. Pretend work.
> will ultimately determine what gets approved
Who then so quickly decided to assign this bug to Hiroyuki?
And why bug 674742 was never assigned for over a year now?
(:aceman #5)
> you propably should have posted to bug 674742 what are you
> splitting out from there.
You write, as if Hiroyuki made a clean new patch.
No. His patch is old, and bad.
This comment of yours proves that you did not read bug 674742. You argue about what you do not know, and will not know, if you dismiss bug 674742.
Hiroyuki's patch was the first in bug 674742.
It was bad. I made such a review in it.
Now he removed that patch from there, and duplicated it here.
He got rid of the review.
This means that he does not want any reviews.
(In reply to Andrew from comment #8)
> Who then so quickly decided to assign this bug to Hiroyuki?
A bug is assigned to whoever makes a patch or wants to work on it. This was the case here, just that Hiro often forgets to set the fields :)
> And why bug 674742 was never assigned for over a year now?
I don't know. Why did you not assign it to yourself if you made a patch there?
> This comment of yours proves that you did not read bug 674742. You argue
> about what you do not know, and will not know, if you dismiss bug 674742.
>
Yes I have not read that bug in full as it is long. I just want to calm down emotions.
> The only thing Kent that failed was to put a review mark to approve my patch, > or part of it. He failed to conclude.
At that time, rkent was not authorised to give r+ mark on patches so you had to find another reviewer according to the module owners wiki page.
Assignee | ||
Updated•12 years ago
|
Assignee: hiikezoe → mbanner
Comment 10•12 years ago
|
||
Still this bug is a duplicate.
This violates your own rules.
Still Hiroyuki by this duplication stripped from the patch my review:
https://bugzilla.mozilla.org/show_bug.cgi?id=674742#c57
He avoids this, and the rest of discussion.
His reason is that there is a discussion (supposedly long).
(:aceman comment #9)
> A bug is assigned to whoever makes a patch or wants to work on it.
Hiroyuki could assign the bug to himself there in bug 674742.
The question was not in whom to assign to, but in the RUSH to assign it here.
And in dragging the feet to assign it there.
> I don't know. Why did you not assign it to yourself
For the whole year I did not know the code.
I asked you to look at it.
Later I showed you the code. And explained that I do not know how to commit changes, because your rules on that are a mess.
I asked you to work.
> if you made a patch there?
I still do not know how to push it. Because your instructions are a mess.
Is this done solely over the web?
Or do I have to download and use some special software?
I would prefer the web: send the file, and let your system compile it.
> Yes I have not read that bug in full as it is long.
You can't judge without reading.
> I just want to calm down emotions.
No emotions. Just rude inaction.
Why then everyone pretends to participate?
If you do not want to act, go aside to have a rest.
Comment 11•12 years ago
|
||
(In reply to Andrew from comment #10)
> Hiroyuki could assign the bug to himself there in bug 674742.
> The question was not in whom to assign to, but in the RUSH to assign it here.
> And in dragging the feet to assign it there.
No rush or dragging, just coincidence that I went along and noticed he didn't assign a bug to himself when he attached a patch.
> For the whole year I did not know the code.
> I asked you to look at it.
> Later I showed you the code. And explained that I do not know how to commit
> changes, because your rules on that are a mess.
> I asked you to work.
Not me. Maybe you mean the bugzilla/mozilla community.
> > if you made a patch there?
>
> I still do not know how to push it. Because your instructions are a mess.
>
> Is this done solely over the web?
> Or do I have to download and use some special software?
> I would prefer the web: send the file, and let your system compile it.
If you collect all the necessary reviews just add a 'checkin-needed' keyword into the keywords field and the right people will merge your patch into the core automatically.
Assignee | ||
Comment 12•12 years ago
|
||
Comment on attachment 659534 [details] [diff] [review]
Proposed fix
We've taken the best ideas and put them in the patch on bug 674742 - we'll finish resolving the compact issue there.
Attachment #659534 -
Flags: review?(mbanner)
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•