On Mon, Oct 13, 2014 at 1:32 AM, Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:

> On Mon, Oct 13, 2014 at 11:25:03AM +0400, Evgeniy Berdnikov wrote:
> > On Mon, Oct 13, 2014 at 12:06:57AM -0700, Wael M. Nasreddine wrote:
> > > new message 25163 on slave
> > >   -> pair(-2,25163) exists
> > >   -> updated flags to 8
> > >   -> pushing message, TUID ZpYx0cJZg8mA
> > > synchronizing flags
> > > propagating new messages
> > > >>> 7 APPEND "Yahoo/Old Inbox" (\Seen) {8360}
> > > + go ahead
> > > (1 in progress) >>> 8 APPEND "Yahoo/Old Inbox" (\Seen) {3569}
> > > * BYE Invalid character in literal
>
> you can add another -V to see what data is being sent. though you could
> end up with utter garbage on the screen. maybe pipe straight to 'less'.
>
>
I added -V but it doesn't show me the file still, I still get the same
output at the end. I am using isync 1.1.0


> > > Socket error: secure read from imap.gmail.com
> ([2607:f8b0:4001:c08::6c]:993):
> > > unexpected EOF
> > >
> i clearly should handle that better ...
>
> > > It seems like an encoding issue to me, how can I find out which file
> is the
> > > problem.
> >
> >  Look for mail with header "X-TUID: ZpYx0cJZg8mA", it should be somewhere
> >  in your local folder, which is counterpart of remote "Yahoo/Old Inbox".
> >
> no, the tuid is *temporary*, that's already in the name. it's box-specific.
>
> the uid (25163) should be possible to find in the maildir by the
> ,U=25163 in the file name.
>

The email with the UID 25163 was actually the very last email and from the
look of it, mbsync was just going through all of them and check if it has
been sent or not (I am assuming from the journal it keeps).

I ended up solving the issue in a different way, there's clearly a better
route for this but here's what I did.

   1. Looked at the output of *mbsync --all* and noticed "slave: 25162
   messages, 0 recent" and "Warning: lost track of 9372 pushed message(s)"
   2. I subtracted 9372 of 25162 and I got 15782
   3. I moved the 3 emails with the UID=15781 UID=15782 and UID=15783
   (because I don't know how mbsync calculate those numbers
   4. Started the sync again and it works
   5. The next step would be to put those 3 emails one by one to find the
   culprit.



>
> btw, it wouldn't have been necessary to use a temporary maildir (and the
> associated cleaning up of the sync state from the fetch) - you can sync
> two imap servers directly.
>

<Off-topic>
I didn't know that I can, that's awesome. Will it handle the errors
correctly as well (Note that Yahoo is no longer receiving any emails so
it's in a fixed state)? How would you go about converting all folders to
sub-folder of a designated root parent?
</Off-topic>


>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> isync-devel mailing list
> isync-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/isync-devel
>



-- 
Wael Nasreddine | SRE at Google | wael.nasredd...@gmail.com | (650) 735-1773
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to