ralph wrote: > Hi Paul (Fox), > > > but looking at rmm.c, refile.c, and folder_delmsgs(), i don't think > > that issue applies. the patch below fixes the problem, and makes > > rmmproc and refile do the right thing (well, at least, the modern > > thing). NB: i didn't test to the limit where execvp should return > > E2BIG. > > When you say it makes refile `do the right thing', do you mean refile > doesn't create copies of the emails if the future rmmproc can't be > invoked? I'm guessing not from the patch's brevity. :-) That means > the user is left with many duplicate emails, most likely with different > numbers, hard-linked across two folders to clean up.
as far as i can tell, this was also true before my change. are you suggesting otherwise? (one way to reduce the likelihood of this, and of the original overflow issue, might be to pass the message arguments to rmmproc in the same form that they were received by refile. currently "refile all" causes a call to rmmproc with a full enumeration of message numbers. if "refile all" instead caused "rmmproc all", on the assumption that the same expansion would result, then the original invocation of refile would be as likely to fail as rmmproc. there are probably subtleties to this i'm not getting right now.) paul =--------------------- paul fox, [email protected] (arlington, ma, where it's 31.8 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
