drag and drop eml to imap folder fails if message is similar on server

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
9 years ago
8 years ago

People

(Reporter: philbaseless-firefox, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2011-03-21])

(Reporter)

Description

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

Comment 1

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

8 years ago
Phil, if you still see this, can you get an imap protocol log please?
Whiteboard: [closeme 2011-03-21]
(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?
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
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.