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
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
