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

Amadeusz Żołnowski

Attachment: signature.asc
Description: PGP signature

notmuch mailing list

Reply via email to