Menu
▾
▴
archivemail-devel — Discussions about archivemail development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(13) |
Nov
(11) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(22) |
Dec
(3) |
| 2008 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(11) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(6) |
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(12) |
Sep
(5) |
Oct
(6) |
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(2) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(4) |
Dec
|
|
From: SourceForge.net <no...@so...> - 2008-10-30 23:26:09
|
Patches item #2210707, was opened at 2008-10-30 19:24 Message generated for change (Settings changed) made by tlitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 6 Private: No Submitted By: tlhackque (tlitt) Assigned to: Nobody/Anonymous (nobody) >Summary: archivemail needs to preserve IMAP dummy message Initial Comment: archivemail will happily delete the dummy message that IMAP servers place in mbox files to keep track of the next UID. This isn't the end of the world, but it is mildly unpleasant. This simple patch will preserve this message. (A more rigorous implemention might ensure that this is the first message in the file.) Enjoy, --tlhackque at nospam.yahoo.com --- /usr/share/archivemail/archivemail.py~ 2007-06-14 11:57:39.000000000 -0400 +++ /usr/share/archivemail/archivemail.py 2008-10-30 18:23:16.000000000 -0400 @@ -981,20 +981,25 @@ # I could probably do this in one if statement, but then I wouldn't # understand it. if not old: return 0 if not options.include_flagged and is_flagged(message): return 0 if options.min_size and is_smaller(message, options.min_size): return 0 if options.preserve_unread and is_unread(message): return 0 + """TL: Do not remove IMAP header message""" + imaphdr = message.get('X-IMAP') + if imaphdr : + vprint("Message is an IMAP mailbox header ('%s')" % imaphdr) + return 0 return 1 def is_older_than_time(time_message, max_time): """Return true if a message is older than the specified time, false otherwise. Arguments: time_message -- the delivery date of the message measured in seconds since the epoch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-30 23:24:14
|
Patches item #2210707, was opened at 2008-10-30 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tlhackque (tlitt) Assigned to: Nobody/Anonymous (nobody) Summary: archivemail needs to preserver IMAP dummy message Initial Comment: archivemail will happily delete the dummy message that IMAP servers place in mbox files to keep track of the next UID. This isn't the end of the world, but it is mildly unpleasant. This simple patch will preserve this message. (A more rigorous implemention might ensure that this is the first message in the file.) Enjoy, --tlhackque at nospam.yahoo.com --- /usr/share/archivemail/archivemail.py~ 2007-06-14 11:57:39.000000000 -0400 +++ /usr/share/archivemail/archivemail.py 2008-10-30 18:23:16.000000000 -0400 @@ -981,20 +981,25 @@ # I could probably do this in one if statement, but then I wouldn't # understand it. if not old: return 0 if not options.include_flagged and is_flagged(message): return 0 if options.min_size and is_smaller(message, options.min_size): return 0 if options.preserve_unread and is_unread(message): return 0 + """TL: Do not remove IMAP header message""" + imaphdr = message.get('X-IMAP') + if imaphdr : + vprint("Message is an IMAP mailbox header ('%s')" % imaphdr) + return 0 return 1 def is_older_than_time(time_message, max_time): """Return true if a message is older than the specified time, false otherwise. Arguments: time_message -- the delivery date of the message measured in seconds since the epoch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=2210707&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-29 00:32:29
|
Feature Requests item #2157804, was opened at 2008-10-10 19:06 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nikolaus Schulz (nikosch) Summary: Match against From, To or Subject fields. Initial Comment: Dear Peter, Nikolaus and Brandon, It would be very interesting if archivemail could match against From, To and Subject header fields. So It would be possible to archive or delete just old informative messages in a automated manner, like "eticket generated", "New order arrived" or from addresses like "et...@do...". I'll be trying archivemail with Maildir. Thank you in advance, Gabriel Goes. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-29 01:32 Message: Hi Peter! I tend to forget about this option. :-) So yes, one can craft IMAP SEARCH commands. But obviously, that doesn't help users with local mailboxes, which is probably the majority. And at least I personally regard --filter-append as a powerful extension interface for IMAP experts, but not something I would like to impose on our typical users. If we want to support some sort of pattern matching in general, we will have to roll our own. ---------------------------------------------------------------------- Comment By: Peter Poeml (poeml) Date: 2008-10-27 04:04 Message: There is an option called --filter-append. I generally use it as "filter-append = 'not FROM poeml@ not ANSWERED not FLAGGED'". If you read up how you specify your criteria in IMAP language, this might do what you want. If you have working example, it could be great to document them. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:23 Message: Well, I'm not sure if this is within the scope of archivemail. Basically, the question is if archivemail should support more complex filter criteria. For example, we could (quite easily) grep the mail headers, or even the body. Would be a rather expensive operation, of course. I postpone this for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-27 03:04:38
|
Feature Requests item #2157804, was opened at 2008-10-10 19:06 Message generated for change (Comment added) made by poeml You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nikolaus Schulz (nikosch) Summary: Match against From, To or Subject fields. Initial Comment: Dear Peter, Nikolaus and Brandon, It would be very interesting if archivemail could match against From, To and Subject header fields. So It would be possible to archive or delete just old informative messages in a automated manner, like "eticket generated", "New order arrived" or from addresses like "et...@do...". I'll be trying archivemail with Maildir. Thank you in advance, Gabriel Goes. ---------------------------------------------------------------------- >Comment By: Peter Poeml (poeml) Date: 2008-10-27 04:04 Message: There is an option called --filter-append. I generally use it as "filter-append = 'not FROM poeml@ not ANSWERED not FLAGGED'". If you read up how you specify your criteria in IMAP language, this might do what you want. If you have working example, it could be great to document them. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:23 Message: Well, I'm not sure if this is within the scope of archivemail. Basically, the question is if archivemail should support more complex filter criteria. For example, we could (quite easily) grep the mail headers, or even the body. Would be a rather expensive operation, of course. I postpone this for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-26 14:42:22
|
Bugs item #2043900, was opened at 2008-08-09 14:47 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) Assigned to: Nikolaus Schulz (nikosch) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:42 Message: Fix committed to git-svn, will make it in archivemail 0.8.0 ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-15 11:44 Message: Logged In: YES user_id=1594781 Originator: NO Okay, I can reproduce the test suite failure with xfs, and the odd 1ms timestamp skew. Thanks for the links, that was very useful. There is no real fix for this problem, I'll simply have to make the timestamp check in the test suite less strict, let it be by rounding or by disabling floating timestamps at all as per os.stat_float_times(). It seems that the next POSIX standard will address the lacking precision of utimes(2) by adding the futimens(2) system call; futimens(2) is already implemented in Linux 2.6.22 and glibc 2.6. But of course, speaking about Python, that buys us nothing. ---------------------------------------------------------------------- Comment By: Andrey Rahmatullin (wrar) Date: 2008-08-14 19:38 Message: Logged In: YES user_id=884799 Originator: YES I use Linux and XFS. I've asked about this problem some time ago and received some interesting answers. You can see the thread in Russian at http://lists.altlinux.org/pipermail/devel/2008-March/071387.html (especially http://lists.altlinux.org/pipermail/devel/2008-March/071492.html). Here are some ideas from that thread: 1. stat(2) uses nanoseconds, while utimes(2) uses milliseconds, so utimes(2) loses precision less than millisecond. 2. os.path.getmtime + os.utime sometimes loses 1ms. You can see the testcases at the provided links. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-14 13:39 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I'm just learning about this; which operating system and which file system are you using? Does your system support the utimes(2) system call? I *think* Python should be able to restore the exact timestamp with utimes(2), if it is available, although the Python documentation nebulously warns that os.utime() might fail to set precise timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-26 14:34:03
|
Feature Requests item #1978540, was opened at 2008-05-30 02:02 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nikolaus Schulz (nikosch) Summary: Archive _all_ imap folders Initial Comment: I've seen that there's a recursive patch in the patch section (which I haven't tried). I have, at the moment, 236 IMAP folders nested in various ways. They are organized in such a way that I don't have to spend much time thinking about where things are. While I certainly could just iterate a list of them all firing off archivemail on each one independently, it would be rather nice if I could just ask archivemail to visit every folder in a single invocation. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:34 Message: Recursive archiving of IMAP folders has already been requested, see tracker item #1918937, which proposed a (rather suboptimal) patch. As I've stated there, I have been reluctant to add yet another feature and option, but I've changed my mind a little bit; archivemail could support IMAP wildcards. Especially there would be no need for a special option. But postponed for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-26 14:24:04
|
Feature Requests item #2157804, was opened at 2008-10-10 19:06 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nikolaus Schulz (nikosch) Summary: Match against From, To or Subject fields. Initial Comment: Dear Peter, Nikolaus and Brandon, It would be very interesting if archivemail could match against From, To and Subject header fields. So It would be possible to archive or delete just old informative messages in a automated manner, like "eticket generated", "New order arrived" or from addresses like "et...@do...". I'll be trying archivemail with Maildir. Thank you in advance, Gabriel Goes. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:23 Message: Well, I'm not sure if this is within the scope of archivemail. Basically, the question is if archivemail should support more complex filter criteria. For example, we could (quite easily) grep the mail headers, or even the body. Would be a rather expensive operation, of course. I postpone this for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-26 14:13:34
|
Feature Requests item #2192775, was opened at 2008-10-24 23:15 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2192775&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Tomas Ebenlendr (ebik) >Assigned to: Nikolaus Schulz (nikosch) Summary: imaplib IMAP_stream support Initial Comment: Add option to use imap constructor imaplib.IMAP_stream(), to let users do alternative IMAP authentications, such as via ssh tunnel. E.g.: let there be option '-t' '--imap-tunnel=' which will be passed directly as argument of IMAP_stream(). Also don't forget to NOT call imap_srv.login() (and do not require password!). ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-10-26 15:13 Message: Ha, that's a cool feature request. I'm just learning that IMAP actually can be tunnelled and how. :-) Okay, this isn't high priority, but it looks interesting and I guess it's quite easy to do, so I'll probably implement it when I need some relaxing from my current, unfortunately less rewarding tasks. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2192775&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-24 21:15:48
|
Feature Requests item #2192775, was opened at 2008-10-24 23:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2192775&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Tomas Ebenlendr (ebik) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib IMAP_stream support Initial Comment: Add option to use imap constructor imaplib.IMAP_stream(), to let users do alternative IMAP authentications, such as via ssh tunnel. E.g.: let there be option '-t' '--imap-tunnel=' which will be passed directly as argument of IMAP_stream(). Also don't forget to NOT call imap_srv.login() (and do not require password!). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2192775&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-10-10 17:06:20
|
Feature Requests item #2157804, was opened at 2008-10-10 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Match against From, To or Subject fields. Initial Comment: Dear Peter, Nikolaus and Brandon, It would be very interesting if archivemail could match against From, To and Subject header fields. So It would be possible to archive or delete just old informative messages in a automated manner, like "eticket generated", "New order arrived" or from addresses like "et...@do...". I'll be trying archivemail with Maildir. Thank you in advance, Gabriel Goes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=2157804&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-08-15 09:44:46
|
Bugs item #2043900, was opened at 2008-08-09 14:47 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) Assigned to: Nikolaus Schulz (nikosch) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-15 11:44 Message: Logged In: YES user_id=1594781 Originator: NO Okay, I can reproduce the test suite failure with xfs, and the odd 1ms timestamp skew. Thanks for the links, that was very useful. There is no real fix for this problem, I'll simply have to make the timestamp check in the test suite less strict, let it be by rounding or by disabling floating timestamps at all as per os.stat_float_times(). It seems that the next POSIX standard will address the lacking precision of utimes(2) by adding the futimens(2) system call; futimens(2) is already implemented in Linux 2.6.22 and glibc 2.6. But of course, speaking about Python, that buys us nothing. ---------------------------------------------------------------------- Comment By: Andrey Rahmatullin (wrar) Date: 2008-08-14 19:38 Message: Logged In: YES user_id=884799 Originator: YES I use Linux and XFS. I've asked about this problem some time ago and received some interesting answers. You can see the thread in Russian at http://lists.altlinux.org/pipermail/devel/2008-March/071387.html (especially http://lists.altlinux.org/pipermail/devel/2008-March/071492.html). Here are some ideas from that thread: 1. stat(2) uses nanoseconds, while utimes(2) uses milliseconds, so utimes(2) loses precision less than millisecond. 2. os.path.getmtime + os.utime sometimes loses 1ms. You can see the testcases at the provided links. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-14 13:39 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I'm just learning about this; which operating system and which file system are you using? Does your system support the utimes(2) system call? I *think* Python should be able to restore the exact timestamp with utimes(2), if it is available, although the Python documentation nebulously warns that os.utime() might fail to set precise timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-08-14 17:38:16
|
Bugs item #2043900, was opened at 2008-08-09 18:47 Message generated for change (Comment added) made by wrar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) Assigned to: Nikolaus Schulz (nikosch) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Andrey Rahmatullin (wrar) Date: 2008-08-14 23:38 Message: Logged In: YES user_id=884799 Originator: YES I use Linux and XFS. I've asked about this problem some time ago and received some interesting answers. You can see the thread in Russian at http://lists.altlinux.org/pipermail/devel/2008-March/071387.html (especially http://lists.altlinux.org/pipermail/devel/2008-March/071492.html). Here are some ideas from that thread: 1. stat(2) uses nanoseconds, while utimes(2) uses milliseconds, so utimes(2) loses precision less than millisecond. 2. os.path.getmtime + os.utime sometimes loses 1ms. You can see the testcases at the provided links. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-14 17:39 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I'm just learning about this; which operating system and which file system are you using? Does your system support the utimes(2) system call? I *think* Python should be able to restore the exact timestamp with utimes(2), if it is available, although the Python documentation nebulously warns that os.utime() might fail to set precise timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-08-14 11:39:44
|
Bugs item #2043900, was opened at 2008-08-09 14:47 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) >Assigned to: Nikolaus Schulz (nikosch) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-08-14 13:39 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I'm just learning about this; which operating system and which file system are you using? Does your system support the utimes(2) system call? I *think* Python should be able to restore the exact timestamp with utimes(2), if it is available, although the Python documentation nebulously warns that os.utime() might fail to set precise timestamps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: Serafeim Z. <se...@he...> - 2008-08-10 23:23:02
|
tags 349068 patch pending tags 247340 patch pending thanks Hi there, Please find attached patches for fixing the overwriting of symlinks [1], and adding a --prefix switch to archivemail [2], along with relevant test cases. Let me know if you'd like any changes for them to be accepted upstream. Cheers, Serafeim [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349068 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247340 |
|
From: SourceForge.net <no...@so...> - 2008-08-09 12:47:49
|
Bugs item #2043900, was opened at 2008-08-09 18:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Rahmatullin (wrar) Assigned to: Nobody/Anonymous (nobody) Summary: mtime tests fail with python 2.5 Initial Comment: ====================================================================== FAIL: mbox timestamps should not change after semi-archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 713, in testMixed self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9247789 != 1218285951.924777 ====================================================================== FAIL: mbox timestamps should not change after no archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 690, in testNew self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9328034 != 1218285951.932802 ====================================================================== FAIL: mbox timestamps should not change after archival ---------------------------------------------------------------------- Traceback (most recent call last): File "./test_archivemail.py", line 736, in testOld self.assertEqual(self.mtime, new_mtime) AssertionError: 1218285951.9367993 != 1218285951.936799 ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=2043900&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-05-30 00:02:16
|
Feature Requests item #1978540, was opened at 2008-05-29 17:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Archive _all_ imap folders Initial Comment: I've seen that there's a recursive patch in the patch section (which I haven't tried). I have, at the moment, 236 IMAP folders nested in various ways. They are organized in such a way that I don't have to spend much time thinking about where things are. While I certainly could just iterate a list of them all firing off archivemail on each one independently, it would be rather nice if I could just ask archivemail to visit every folder in a single invocation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456913&aid=1978540&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-03-19 21:13:07
|
Patches item #1918937, was opened at 2008-03-19 00:36 Message generated for change (Comment added) made by chrisbra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian (chrisbra) Assigned to: Nobody/Anonymous (nobody) Summary: recursively archive all mails from an imap server Initial Comment: Hi, I thought, it would be nice, if archivemail could automatically archive messages from all folders in an imap server. This could for example be used for migrating all mails from one imap-server to another server. Attached is my first try to achieve this. I am not sure, how stable it is, especially the naming of the final archive could probably be improved and I am not sure how well this works with other imap servers beside cyrus, with which I've tested it. Greetings, C.Brabandt ---------------------------------------------------------------------- >Comment By: Christian (chrisbra) Date: 2008-03-19 22:13 Message: Logged In: YES user_id=1928606 Originator: YES Oh well, that was what I meant with "...especially the naming of the final archive could probably be improved..." (without that line all messages would be archived into the same archive, which is probably not what would be expected, so I thought of a way to add the folder. This was a quick and dirty solution to create a new archive for each folder without adding too much complexitiy by refactoring the code for determining the final_archive_name. I was not sure how else to create an appropriate name for each subfolder. May be one can find a much better solution. Perhaps one can simply append the folder name to final_archive_name, of course the folder_name must at least be matched against "/" which needs to be replaced. Besides I noticed one probably needs to change the way, how the subfolders are determined. So this line: result, response = imap_server.list() should probably take the submitted folder_name into account, like this: result, response = imap_server.list(folder_name+"*") to take into account that the use only wants the subfolders below the one he specified and not all subfolders that exist. So I see your point, and the patch was kind of a starting point which I created quickly yesterday ;) Thanks for your comments, I'd obviously like to see this feature implemented ;) regards, Christian ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-03-19 21:02 Message: Logged In: YES user_id=1594781 Originator: NO Hm, okay, I see that this can be convenient. I'm not convinced that it's worth adding more complexity and yet another option to archivemail, though... I would expect that typically, mailboxes are pretty static objects; you don't create them often or move them around a lot, so the benefit of recursive archiving seems pretty small. By the way, this has already been requested a long time ago before I was involved with archivemail, but the tracker was closed by the maintainer for some reason, see Feature request #649607. Finally, can you please explain the following line from your patch? final_archive_name = "INBOX" + folder.replace("INBOX","") + o_fan.replace("INBOX","") First, this looks like you're assuming that all folders are below INBOX, which need not be the case. Also, one would have to catch if 'folder' in the assignment contains slashes. But leaving that aside, I don't understand it. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-03-19 20:02:03
|
Patches item #1918937, was opened at 2008-03-19 00:36 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian (chrisbra) Assigned to: Nobody/Anonymous (nobody) Summary: recursively archive all mails from an imap server Initial Comment: Hi, I thought, it would be nice, if archivemail could automatically archive messages from all folders in an imap server. This could for example be used for migrating all mails from one imap-server to another server. Attached is my first try to achieve this. I am not sure, how stable it is, especially the naming of the final archive could probably be improved and I am not sure how well this works with other imap servers beside cyrus, with which I've tested it. Greetings, C.Brabandt ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-03-19 21:02 Message: Logged In: YES user_id=1594781 Originator: NO Hm, okay, I see that this can be convenient. I'm not convinced that it's worth adding more complexity and yet another option to archivemail, though... I would expect that typically, mailboxes are pretty static objects; you don't create them often or move them around a lot, so the benefit of recursive archiving seems pretty small. By the way, this has already been requested a long time ago before I was involved with archivemail, but the tracker was closed by the maintainer for some reason, see Feature request #649607. Finally, can you please explain the following line from your patch? final_archive_name = "INBOX" + folder.replace("INBOX","") + o_fan.replace("INBOX","") First, this looks like you're assuming that all folders are below INBOX, which need not be the case. Also, one would have to catch if 'folder' in the assignment contains slashes. But leaving that aside, I don't understand it. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-03-18 23:36:37
|
Patches item #1918937, was opened at 2008-03-19 00:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian (chrisbra) Assigned to: Nobody/Anonymous (nobody) Summary: recursively archive all mails from an imap server Initial Comment: Hi, I thought, it would be nice, if archivemail could automatically archive messages from all folders in an imap server. This could for example be used for migrating all mails from one imap-server to another server. Attached is my first try to achieve this. I am not sure, how stable it is, especially the naming of the final archive could probably be improved and I am not sure how well this works with other imap servers beside cyrus, with which I've tested it. Greetings, C.Brabandt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1918937&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-03-16 02:30:38
|
Patches item #1764846, was opened at 2007-07-31 21:19 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1764846&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nikolaus Schulz (nikosch) Summary: Option to archive all available mail Initial Comment: Hi, thanks for working on archivemail. I think an option --archive-all would be useful. Attached is a patch, that would add that option and archive all available mails. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-03-16 03:30 Message: Logged In: YES user_id=1594781 Originator: NO This idea has cropped up again in the Debian BTS. The next archivemail release will have an --all option, as requested. ---------------------------------------------------------------------- Comment By: Christian (chrisbra) Date: 2007-11-13 23:39 Message: Logged In: YES user_id=1928606 Originator: NO ok, whatever you like more is fine with me. Christian ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-05 22:03 Message: Logged In: YES user_id=1594781 Originator: NO That's interesting. I don't know why, but I really didn't consider your approach; I have a different, "optimized" implementation of --archive-all. I'm attaching the patch; it applies against the current trunk. Actually I'm not sure which of the two patches is cleaner. Or should I say "less unclean"? Well. Perhaps I should postpone this decision for the v0.7.1 release. Nikolaus File Added: archivemail-all-optim.diff ---------------------------------------------------------------------- Comment By: Christian (chrisbra) Date: 2007-11-03 13:55 Message: Logged In: YES user_id=1928606 Originator: NO Hi, sorry, I must have made a mistake when submitting the patch. But if it is true, that --archive-all will be the same as --days=0 and --include-flagged, then the following patch should achieve it (against 0.7.0): --- archivemail.orig 2007-11-03 13:36:10.000000000 +0100 +++ archivemail.all 2007-11-03 13:35:55.000000000 +0100 @@ -201,7 +201,7 @@ """ try: opts, args = getopt.getopt(args, '?D:S:Vd:hno:F:P:qs:uv', - ["date=", "days=", "delete", "dry-run", "help", + ["archive-all", "date=", "days=", "delete", "dry-run", "help", "include-flagged", "no-compress", "output-dir=", "filter-append=", "pwfile=", "dont-mangle", "archive-name=", @@ -213,6 +213,13 @@ archive_by = None for o, a in opts: + if o == '--archive-all': + if archive_by: + user_error("you cannot specify --archive-all and -d or -D options") + archive_by = "all" + self.archive_all = 1 + self.days_old_max = 0 + self.include_flagged = 1 if o == '--delete': self.delete_old_mail = 1 if o == '--include-flagged': @@ -223,12 +230,12 @@ self.warn_duplicates = 1 if o in ('-D', '--date'): if archive_by: - user_error("you cannot specify both -d and -D options") + user_error("you cannot specify --archive-all and -d or -D options") archive_by = "date" self.date_old_max = self.date_argument(a) if o in ('-d', '--days'): if archive_by: - user_error("you cannot specify both -d and -D options") + user_error("you cannot specify --archive-all and -d or -D options") archive_by = "days" self.days_old_max = string.atoi(a) if o in ('-o', '--output-dir'): @@ -647,6 +654,7 @@ mailbox compressed with gzip. Options are as follows: + --archive-all archive all messages -d, --days=NUM archive messages older than NUM days (default: %d) -D, --date=DATE archive messages older than DATE -o, --output-dir=DIR directory to store archives (default: same as original) regards, Christian ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-01 13:57 Message: Logged In: YES user_id=1594781 Originator: NO archivemail 0.7.1 will accept --days=0. Add --include-flagged, and you get the same effect. Still, I think a shortcut like --archive-all can be handy. The patch is incomplete, however, it only covers IMAP. Nikolaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1764846&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-03-15 18:49:31
|
Patches item #1878940, was opened at 2008-01-24 15:44 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1878940&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Aidant (wtfoguru) >Assigned to: Nikolaus Schulz (nikosch) >Summary: empty Maildir fix for Python 2.5 Initial Comment: when archiving an empty maildir an assertion is generated this patch fixes that ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-03-15 19:49 Message: Logged In: YES user_id=1594781 Originator: NO Thanks for spotting this; another incompatibility in Python 2.5. :-/ Fixed in subversion, will be in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1878940&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-01-24 14:44:09
|
Patches item #1878940, was opened at 2008-01-24 07:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1878940&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aidant (wtfoguru) Assigned to: Nobody/Anonymous (nobody) Summary: empty Maildir fix Initial Comment: when archiving an empty maildir an assertion is generated this patch fixes that ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1878940&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-01-21 12:33:47
|
Bugs item #1753702, was opened at 2007-07-13 12:36 Message generated for change (Comment added) made by limburgher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=1753702&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jonathan Ciesla (limburgher) Assigned to: Nikolaus Schulz (nikosch) Summary: crashes on zero-size mbox folder. Initial Comment: Traceback (most recent call last): File "/usr/bin/archivemail", line 6, in <module> main() File "/usr/share/archivemail/archivemail.py", line 686, in main archive(mailbox_path) File "/usr/share/archivemail/archivemail.py", line 1125, in archive new_temp_dir = tempfile.mkdtemp('archivemail') File "/usr/lib/python2.5/tempfile.py", line 320, in mkdtemp dir = gettempdir() File "/usr/lib/python2.5/tempfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/usr/lib/python2.5/tempfile.py", line 209, in _get_default_tempdir ("No usable temporary directory found in %s" % dirlist)) IOError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/root'] Happens on some empty folders. Does not happen on others. Not sure why, all the listed temp dirs exist on my systems. If I edit my wrapper script to only run archivemail against nonzero size boxes, i only get one error. Not sure who, but I have one user who's at quota. I'm the Fedora maintainer for this, so I'll submit a patch if I find a solution. ---------------------------------------------------------------------- >Comment By: Jonathan Ciesla (limburgher) Date: 2008-01-21 06:33 Message: Logged In: YES user_id=791236 Originator: YES Nah, I'll close it. Thanks. :) ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2008-01-18 20:04 Message: Logged In: YES user_id=1594781 Originator: NO This doesn't look like an archivemail bug. Jonathan, you've got a last chance to pick it up, otherwise the BTS bot will close this tracker in the next days. :-) ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-09 11:12 Message: Logged In: YES user_id=1594781 Originator: NO I strongly doubt newer archivemail versions will behave differently. Can we agree to close this bug? Looks like it's just the quota that's barfing, so it's not related to archivemail. ---------------------------------------------------------------------- Comment By: Jonathan Ciesla (limburgher) Date: 2007-11-09 05:08 Message: Logged In: YES user_id=791236 Originator: YES Actually, you're right, it is quota related. Though it may not occur with 0.7.1, so I'll check and let you know. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-08 21:23 Message: Logged In: YES user_id=1594781 Originator: NO I don't see how this relates to the mailboxes in question, since at this point, archivemail may have checked if the mailbox exists, and may have seteuid() to the owners uid, but it has not yet opened the mailbox. The error is pretty bizarre. Did you try to track this down? I would guess this might be related to your quota, although I barely know about quotas. :-) Nikolaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=1753702&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-01-19 02:04:53
|
Bugs item #1753702, was opened at 2007-07-13 19:36 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=1753702&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Jonathan Ciesla (limburgher) Assigned to: Nikolaus Schulz (nikosch) Summary: crashes on zero-size mbox folder. Initial Comment: Traceback (most recent call last): File "/usr/bin/archivemail", line 6, in <module> main() File "/usr/share/archivemail/archivemail.py", line 686, in main archive(mailbox_path) File "/usr/share/archivemail/archivemail.py", line 1125, in archive new_temp_dir = tempfile.mkdtemp('archivemail') File "/usr/lib/python2.5/tempfile.py", line 320, in mkdtemp dir = gettempdir() File "/usr/lib/python2.5/tempfile.py", line 262, in gettempdir tempdir = _get_default_tempdir() File "/usr/lib/python2.5/tempfile.py", line 209, in _get_default_tempdir ("No usable temporary directory found in %s" % dirlist)) IOError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/root'] Happens on some empty folders. Does not happen on others. Not sure why, all the listed temp dirs exist on my systems. If I edit my wrapper script to only run archivemail against nonzero size boxes, i only get one error. Not sure who, but I have one user who's at quota. I'm the Fedora maintainer for this, so I'll submit a patch if I find a solution. ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-01-19 03:04 Message: Logged In: YES user_id=1594781 Originator: NO This doesn't look like an archivemail bug. Jonathan, you've got a last chance to pick it up, otherwise the BTS bot will close this tracker in the next days. :-) ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-09 18:12 Message: Logged In: YES user_id=1594781 Originator: NO I strongly doubt newer archivemail versions will behave differently. Can we agree to close this bug? Looks like it's just the quota that's barfing, so it's not related to archivemail. ---------------------------------------------------------------------- Comment By: Jonathan Ciesla (limburgher) Date: 2007-11-09 12:08 Message: Logged In: YES user_id=791236 Originator: YES Actually, you're right, it is quota related. Though it may not occur with 0.7.1, so I'll check and let you know. ---------------------------------------------------------------------- Comment By: Nikolaus Schulz (nikosch) Date: 2007-11-09 04:23 Message: Logged In: YES user_id=1594781 Originator: NO I don't see how this relates to the mailboxes in question, since at this point, archivemail may have checked if the mailbox exists, and may have seteuid() to the owners uid, but it has not yet opened the mailbox. The error is pretty bizarre. Did you try to track this down? I would guess this might be related to your quota, although I barely know about quotas. :-) Nikolaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456910&aid=1753702&group_id=49630 |
|
From: SourceForge.net <no...@so...> - 2008-01-19 00:57:08
|
Patches item #1874868, was opened at 2008-01-18 17:58 Message generated for change (Comment added) made by nikosch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1874868&group_id=49630 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Private: No Submitted By: Tim O'Donnell (tim_odonnell) >Assigned to: Nikolaus Schulz (nikosch) Summary: Allow writing to world-writable directory with sticky bit Initial Comment: Current behavior: If the destination directory is world-writable, halt. New behavior: If the destination directory is world-writable, then proceed only if the directory's sticky bit is set. Rationale: If the destination directory is world-writable with the sticky bit set, then only the user who owns the archived file (or the owner of the directory) can delete it. From the user's perspective, it's equivalent to the directory not being world-writable, so there's no need for concern. I'm including an svn diff of the quick change. If you'd like this another way, just let me know. Thanks! Tim ---------------------------------------------------------------------- >Comment By: Nikolaus Schulz (nikosch) Date: 2008-01-19 01:57 Message: Logged In: YES user_id=1594781 Originator: NO I do not feel comfortable applying this patch. archivemail's file operations are quite sloppy, it uses high-level utilities (the shutil module) and thereby pretty much trusts its environment. Actually, I think archivemail needs be fixed here, but it is not trivial. As matters stand, there are at least two potentially raceable spots: when archivemail reads an already existing archive, and when it writes the new archive. Consider this example: the destination directory is a sticky /tmp, no archive exists yet. archivemail starts, archiving to a safe temporary file. Note that the environment variables $TMPDIR, $TEMP, and $TMPDIR all override /tmp as a place for temporary files. Now when archivemail's done, it first tries to rename the tempfile to the final destination, which is safe, albeit not entirely without problems (it silently overwrites an existing archive, which you might just be reading, if it already existed before). But this e.g. fails if the temporary file and /tmp are not on the same filesystem; in this case, archivemail essentially does a 'cp -p <tempfile> <dest>', which follows symlinks! So an attacker could easily drop a symlink in /tmp and cause archivemail to overwrite the link target. Similarly, an attacker can inject any file's content into the archive when archivemail tries to read an existing archive in /tmp. So, until this sloppiness is fixed, I prefer to leave the current check alone. One might argue, of course, that it's not smart to try to stop the user from doing dangerous things like that. But then, I think it makes more sense to remove the entire check than to special-case the /tmp scenario. Nikolaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=456912&aid=1874868&group_id=49630 |
1 message has been excluded from this view by a project administrator.
