Ken Hornstein <k...@pobox.com> 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
