[Mailman-Users] Renaming a list
cnulk at scu.edu
Thu Mar 24 12:17:24 EDT 2016
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)
>> 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)
> 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.
More information about the Mailman-Users