[Mailman-Users] Renaming a list

[Chris Nulk]

On 3/23/2016 6:42 PM, Mark Sapiro wrote:
> On 03/23/2016 11:15 AM, Chris Nulk wrote:
>> I have done limited testing (4 member list with a few archived messages)
>> and it appears to be working.  The archives were moved and rebuilt.
>> When I changed the scrub_nondigest setting to Yes, the list is renamed,
>> archives moved, and an error message that the archives were not rebuilt.
>
> Actually, is scrub_nondigest is Yes, bin/arch --wipe will work but there
> are lots of caveats. In this case, bin/arch --wipe will just not remove
> the 'attachments' directory. The issue is if scrub_nondigest was always
> Yes for this list, that's the right thing to do, but it it was No at
> some time in the past and changed to Yes, there are already two copies
> of each attachment from the No period (one scrubbed from the archive and
> one from the plain digest) and running bin/arch --wip will leave those
> and create  third copies from the attachments in the mbox.
>
> The more serious issue is if scrub_nondigest was Yes at some time in the
> past and is now No, bin/arch --wipe will lose the attachments from the
> Yes period.
>
> In any case, for attachments scrubbed by scrub_nondigest, there are
> links to them in the message bodies in the mbox and the list names in
> those links will now be wrong, and bin/arch won't (can't) fix them.
>
> This is why I chose in my script to kick the issue back to the user.

I figured it was a bit more complicated.  So, there is still a 
possibility of losing data if scrub_nondigest is No since the list 
doesn't maintain a history of previous settings.

>
>
>> Based on my testing, I noticed the error message for not rebuilding the
>> archives is a bit terse.  For my target audience it needs to be a little
>> more helpful.  So, I changed the lines:
>>
>>         if ol.scrub_nondigest:
>>              abort('Scrub_nondigest is YES for %s.  WILL NOT REBUILD
>> ARCHIVES.' % ns.old_list)
>>         else:
>>
>> with
>>
>>          if ol.scrub_nondigest:
>>              abort("""ARCHIVES NOT REBUILT.
>>
>> Scrub_nondigest for %s is set to Yes.  To prevent losing any scrubbed
>> attachments, you will need to rebuild and fix the listname links in
>> the archives using another method than using bin/arch.
>> """ % ns.old_list)
>>          else:
>
> That much seems good, but as I note above it's a bit more complicated if
> the scrub_nondigest setting has changed over time.

I did a little searching around our lists.  It seems the attachments 
directory is always created and populated whether or not scrub_nondigest 
was ever set to Yes.  So I can't really use the existence of the 
attachments directory or the lack of it being populated as a check for 
if scrub_nondigest was ever set to Yes.

Is the anything that can be checked for that would indicate 
scrub_nondigest was Yes at any point in the past?  Obviously, if it is 
currently Yes it doesn't matter.

Lacking the ability to check,  I suppose a warning should be generated 
prior to running the bin/arch.  In addition, the '-b/--rebuild_archives' 
option should default to false unless there is a positive indication the 
user wants to run it ('-b y / --rebuild_archives=Yes').  The default for 
the rebuild_archives option would be No.

If there is any way to tell if scrub_nondigest has been set to Yes in 
the list's past, please let me know.  I am going to add the warning and 
try making the changes to the rebuild_archives options. I will post the 
diff from the Mark's original clone_list.

Thanks Mark,
Chris