| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
In particular:
* we no longer use shutil.copy{,2} to write back a changed mbox
* having temporary mbox files in the same directory as the originals doesn't
make sense anymore since we no longer commit them with rename(2)
* the --archive-name option is now implemented
|
| |
|
|
|
|
|
|
|
| |
Document the --archive-name option, and explain the basic idea of deriving the
archive filename from the mailbox earlier and more prominently. Also document
how archivemail tries not to create hidden archive files, and remove some
obsolete notes.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Archive name prefixes may contain path components, thus renaming some
variables accordingly.
|
|
|
|
|
|
|
|
| |
the name
When archiving a mailbox with leading dots in the name and no archive name
prefix specified, strip the dots off the archive name. This is targeting
Maildir++ subfolders.
|
|
|
|
| |
Also add more archive name affix testing to the test suite.
|
|
|
|
|
|
|
|
|
|
|
| |
Technically, this works just like the --suffix option. This commit also
updates the manpage accordingly.
Currently, the prefix is not checked for slashes, so it could contain path
components. (The same applies for the suffix, btw). Since the expanded
string is prepended to the archive base name, this can be used to dynamically
configure the archive directory, depending on the archive cutoff date. I'm
not sure if this can be considered a reasonable feature, though.
|
|
|
|
|
|
|
| |
IMAP servers (Dovecot and UW-IMAP at least) may store mailbox meta data for
mboxes in a pseudo message. Such messages are now detected and never archived.
This commit includes a test case in the test suite.
|
|
|
|
| |
Add references to bug numbers and be more verbose.
|
| |
|
|
|
|
|
|
| |
If we don't have sufficient permissions to create a dotlock for an mbox file,
record that, and don't try to remove the dotlock when unlocking the mbox
later.
|
|
|
|
|
| |
Better don't write "soon there will be... <foo>" and don't be specific about
available versions. Writing it more generically means lesser maintenance. :)
|
| |
|
| |
|
| |
|
|
|
|
| |
This feature has been removed.
|
|
|
|
|
| |
Recent distutils versions always generate a new MANIFEST, overwriting our
custom one. See Python bug #8688.
|
|
|
|
|
|
|
|
|
| |
On Unix, most scripts don't come with a file extension, it's not needed, and
we distribute the script as "archivemail" anyway. And most importantly, I
like it better without the extension. :)
With a little trick we can still load the script as a module from the test
suite.
|
|
|
|
| |
With the recent optimizations of the test suite, it has become quite fast.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Notable items that are now resolved or implemented:
* archives are now locked
* the mbox classes have been refactored to a cleaner design
* we moved from flock locking to fcntl
* the setuid() feature is long gone
* symlink attacks for tempfiles are not possible (that is really an
ancient TODO item from the original author)
* the test suite now has a lot of maildir test cases
|
|
|
|
| |
Maildir testing should now be roughly on par with mbox testing.
|
|
|
|
|
| |
For cleanup of temporary files, we lean on shutil.rmtree anyway, so don't
bother wasting more code on this.
|
|
|
|
|
|
|
|
|
|
| |
I just discovered that archivemails MH support is broken with respect to
message flags, and in my opinion it doesn't make much sense to test
known-broken functionality.
In fact there may well be zero archivemail users with MH mailboxes; MH is
basically an obsolete format, and any archivemail user with MH mailboxes would
probably have complained about lost message flags.
|
| |
|
| |
|
|
|
|
|
|
| |
This code is complex, too complex actually. Rename some methods and
variables, rework some code and and add some explaining comments in order to
make it it least a bit easier to understand.
|
|
|
|
|
| |
This test case is obsolete since we no longer replace the mbox file with a new
copy but rewrite it.
|
| |
|
| |
|
| |
|
|
|
|
| |
assert is not a function.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This closes a very unlikely window where we could create a dotlock file, but
then encounter an error and fail to clean up the dotlock.
|
| |
|
| |
|
|
|
|
|
|
| |
This should minimize the risk of data loss. Flushing a locked mbox file
before unlocking it also ensures that there's no window when another
process could lock the mbox after us, but still see the old content.
|
|
|
|
|
|
| |
The mbox locking methods move into a new class LockableMboxMixin, and the
Mbox and ArchiveMbox classes become subclasses of LockableMboxMixin.
class StaleFiles is updated to handle multiple dotlock files.
|
|
|
|
|
|
|
|
|
|
| |
In particular:
* If writing the archived messages to the final archive fails, try to
restore the archive and abort (by not handling the exception). This is
possible since we first save the archive, and only then the modified
mailbox, so we don't corrupt the original mbox in this case.
* If writing a modified mbox file fails, save the temporary copy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RetainMbox and ArchiveMbox classes are now gone, mainly because their
finalise() methods were messing with the archived mbox and the archive,
respectively, which was not good OO design.
The core functionality of the finalise() methods of both removed classes
is moved to the objects that are manipulated: the Mbox class representing
the mbox that is being archived gains a new method overwrite_with(), and
there is a new class ArchiveMbox that represents the actual archive, which
has an append() method (yes, unfortunately the new class has the same name
like the removed class).
The RetainMbox instance is replaced with a TempMbox, and the ArchiveMbox
instance either with a TempMbox, or a CompressedTempMbox if archive
compression is enabled.
Finally, a compressed TempMbox is now a implemented as a subclass of
TempMbox, named CompressedMbox.
Cooperation with the StaleFiles class moves into the TempMbox class.
This means slightly less detailed verbose cleanup reporting, oh well.
|
| |
|
|
|
|
| |
Closes: issue #855269.
|