Closed
Bug 544770
Opened 15 years ago
Closed 14 years ago
drag and drop eml to imap folder fails if message is similar on server
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: philbaseless-firefox, Unassigned)
Details
(Keywords: regression, Whiteboard: [closeme 2011-03-21])
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100207 Shredder/3.2a1pre
1 compose simple email file and save to disk
2 drag to imap folder. And view as correct
3 edit same file on disk by only modifying text/plain
4 drag to imap folder.
5 observe error, imap message has not changed
6 delete imap file and repeat
7 observe error, imap message is still original
changing name of file on disk has no improved effect.
changing subject copies edited file ok.
marking regression because I'm reasonably sure I use to be able to copy as many identical files to imap as I wanted. I have older version I can check tomorrow if regression isn't confirmed by then.
Bug 171907 implements the dnd feature.
This really need someone else to confirm it as a bug, maybe it is withing normal operation or within rfc or other reason it is invalid
Also it needs confirmation of regression status
Status: NEW → UNCONFIRMED
Ever confirmed: false
Comment 2•14 years ago
|
||
Phil, if you still see this, can you get an imap protocol log please?
Whiteboard: [closeme 2011-03-21]
Comment 3•14 years ago
|
||
(In reply to comment #0)
> Shredder/3.2a1pre
No problem if Tb 3.1?
> 3 edit same file on disk by only modifying text/plain
What operation do you call "only modifying text/plain"?
Change text data in text/plain part only or change mail body text data of text/plain mail?
> 4 drag to imap folder.
> 5 observe error, imap message has not changed
What phenomenon do you call by "error"?
Rejected by server wih error message such as "bare new line is not permited"?
> 7 observe error, imap message is still original
Because there is no way to replace/modify existent mail data, mail data of an UID won't never be altered by any client operation.
As "Drag&Drop of .eml file" is upload operation, IMAP client uses append command and pass mail data to server, and IMAP server generates mail data of new UID.
To do "replace like operation", same procedure as one on draft mail is required.
Edit Draft. Content of mail of UID=10 is shown
Save As Draft
=> append new draft version, UID=11 is generatd by server
store \Deleted flag to mail of UID=10
What UID is assigned to the "original"?
Show "Order Received" column. Shown value is UID of mail if IMAP.
> changing subject copies edited file ok.
If Gmail IMAP, it's normal phenomenon.
Gmail doesn't keep multiple versions of same mail. If Gmail considers newly upload mail as "same mail as existent mail", Gmail IMAP behaves like next.
append, upload mail data
OK, and perhaps returns new UID for appended mail(UIDPLUS is supported)
If difference is mail body text only, Gmail perhaps considers same mail as
existent mail.
In this case, Gmail IMAP doesn't generate mail data of the "new UID".
So, after that, it looks next for Tb.
appended new UID is deleted by other IMAP client just after append,
and the appended new UID is expunged by other IMAP client
Becase Gmail always considers that mail of different subject is different mail, new UID is really generated.
If you server behaves like Gmail, and if the "error" what you call is "new UID generated by append disappears", phenomenon you saw can happen.
If trunk only problem, it may be offline-copy and Gloda relevant issue. Gloda also can detect duplicated mail.
Do you see problem with offline-use=off folder?
Comment 4•14 years ago
|
||
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•