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

[norm]

Ken Hornstein <address@hidden> writes:
>>> 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.

The special case that the destination folder is the same as the source folder,
might cause a problem?


    Norman Shapiro