-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v2] Fallback MOVE by COPY+STORE+EXPUNGE doesn't return DestUIDs #623
Comments
Or wait, it's impossible by RFCs spec? |
In Client.Move, when falling back to COPY + STORE + EXPUNGE, we might receive a tagged COPYUID response code. Populate MoveCommand in that case. Closes: #623
Does #624 help? Note, these fields are only populated if the server supports UIDPLUS. |
I'll try it and report later. Thanks! |
I just figured out that COPY+STORE+EXPUNGE should already work fine without the PR, if underlying IMAP server supports needed features. Sorry, my fail. I'll check more details better next time. However the PR itself should fix independent COPY command, isn't it? |
The patch is supposed to fix the case where the server does not support MOVE, but does support UIDPLUS. There is nothing we can populate the fields with when the server does not support UIDPLUS. |
Yes, right. I mean your current version without patch already should work fine as far as possible, even when it's MOVE under the hood, because |
There's one detail though: this function handles untagged responses only. Tagged responses are handled elsewhere: Line 711 in ee36cf4
The RFC specifies that |
I gathered CAPABILITIES from underlying accounts, and unfortunely I have no "test subjects" without MOVE support at the moment, so I cannot actually check if the PR does anything. |
v2.0.0-beta.3
The resulting
MoveData.DestUIDs
gets fulfilled only when real MOVE executed.go-imap/imapclient/client.go
Lines 848 to 852 in ee36cf4
In case of fallback workflow COPY+STORE+EXPUNGE it remains
nil
.The text was updated successfully, but these errors were encountered: