nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] refile's -retainsequences switch


From: Ken Hornstein
Subject: Re: [Nmh-workers] refile's -retainsequences switch
Date: Sun, 20 Apr 2014 12:41:26 -0400

>> I don't have the time to spend debugging it right now.
>
>Would you put it on your todo list so that, if you ever get time and
>inclination, you will fix it.

A code inspection suggested to me that it should have worked; everything
was happening where it was supposed to.  It was bugging me, so I took a
closer look at it.

Normally a call to seq_save() saves the sequences.  For public sequences,
this causes the sequence file to be written out.  For private sequences,
it causes the sequences to be added to the context structure (and the
context structure is marked as being modified).

In the private sequence case, you need to make sure that context_save() is
called after seq_save().  Normally this is done everywhere ... except in
the case of refile -retainseq.  seq_save() is called on the source folder
before context_save(), but for the destination folders seq_save is called
by the function clsfolds().  And clsfolds() is called _after_ the call
to context_save (or folder_delmsgs(), which also calls context_save()).

I see two solutions: call clsfolds() before the call to folder_delmsgs()/
context_save(), or call context_save() again after the call to clsfolds().
I do not know if there are any side effects for the first solution (I think
not); for the latter solution in the worst case that would involve
two writes of the context file for private sequences (context_save()
will not write the context file if nothing has changed).

Thoughts?  Seems like a legitimate bug fix that should be able to make
it into 1.6.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]