Hi David, (Resending, because I forgot to Cc mailing list.)
David Mazieres <dm-list-email-notm...@scs.stanford.edu> writes: >> 3. I run muchsync SERVER. >> 4. When it lasted much longer then initialization I canceled it by >> single SIGINT (^c). > > Interesting. I wish I knew why this was taking much longer than running > it on the server, and whether the delay was caused by client activity or > server activity. I think there was something happening on server side because with --noup it has been completed in few seconds. > I don't suppose you'd be willing to make a copy of your mail database > to repeat the experiment without any risk of messing up your real > maildir? I would try it, but unfortunately I would have to make a bit more space for having second copy of my mail. I am testing muchsync on the same machine between different users home directories, so it already takes some space. I'll try the experiment some day this week, I hope. >> 5. I rerun muchsync SERVER and then it notified me that notmuch >> identified files names changes - more than 1000. > > Were the link changes on the client (sent) or the server (received) > side? On the server side. That's why I am worried. > I don't think that will change things. maildir.synchronized_flags > will make things slower, but it shouldn't affect the SUMMARY numbers > you see at the end of muchsync, other than maybe files moving from > .../new to .../cur. But presumably most of your mail files were > already in cur directories. So what would happen on my machine is that first client initialization took place. During this stage muchsync moved some files from new/ to cur/. Later running "muchsync SERVER" tried to reflect client changes on server by pushing renames requests to server. Is it what actually could happend? -- Amadeusz Żołnowski
signature.asc
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch