tags 549736 + patch
thanks
*hem*
On Wed, Oct 07, 2009 at 07:04:08PM +0200, Lucas Nussbaum wrote:
> On 07/10/09 at 19:02 +0200, Serafeim Zanikolas wrote:
> > Thanks for this bug report.
> >
> > On Mon, Oct 05, 2009 at 08:37:54PM +0200, Lucas Nussbaum wrote [edited]:
> > > > ======================================================================
> > > > FAIL: mbox timestamps should not change after semi-archival
> > > > ----------------------------------------------------------------------
> > > > Traceback (most recent call last):
> > > > File "./test_archivemail.py", line 744, in testMixed
> > > > self.assertEqual(self.mtime, new_mtime)
> > > > AssertionError: 1254761568.6369736 != 1254761568.636972
> > [..]
> >
> > This is intriguing because archivemail hasn't changed at all for over a
> > year.
> >
> > It seems that on amd64, mstat is more accurate (the decimal part is no
> > longer
> > zero) which reveals that the mbox _is_ actually modified when in fact it
> > shouldn't. But I still don't understand why this didn't happen before.
> >
> > I'll prepare a fix as soon as I get access to an amd64 box.
>
> I'm building on tmpfs. It probably explains why mtime is more accurate.
Yes. This one is easy. There has been a similar report for an XFS
filesystem to the upstream BTS[1]. I would like to note that it is only
the test suite which fails here, there is no bug in archivemail itself.
The following fix is from my git repository:
commit f22b21738d77aa0fe13fe0fea0288ec9a2dc456c
Author: Nikolaus Schulz <microsch...@web.de>
Date: Mon Sep 29 03:05:57 2008 +0200
test suite: account for lacking precision of os.utime()
os.utime() uses the utimes(2) system call to set file timestamps. utimes(2)
has a microsecond resolution, but stat(2) may return timestamps with
nanosecond resolution. So, the check that we have properly reset the mbox
file timestamp must allow a minor deviation.
diff --git a/test_archivemail.py b/test_archivemail.py
index 8cbf152..01f2c01 100755
--- a/test_archivemail.py
+++ b/test_archivemail.py
@@ -69,6 +69,9 @@ except ImportError:
print "Try renaming it from 'archivemail' to 'archivemail.py'."
sys.exit(1)
+# precision of os.utime() when restoring mbox timestamps
+utimes_precision = 5
+
class TestCaseInTempdir(unittest.TestCase):
"""Base class for testcases that need to create temporary files.
@@ -642,8 +645,8 @@ class TestArchiveMboxTimestamp(TestCaseInTempdir):
assert(os.path.exists(self.mbox_name))
new_atime = os.path.getatime(self.mbox_name)
new_mtime = os.path.getmtime(self.mbox_name)
- self.assertEqual(self.mtime, new_mtime)
- self.assertEqual(self.atime, new_atime)
+ self.assertAlmostEqual(self.mtime, new_mtime, utimes_precision)
+ self.assertAlmostEqual(self.atime, new_atime, utimes_precision)
def testMixed(self):
"""mbox timestamps should not change after semi-archival"""
@@ -663,8 +666,8 @@ class TestArchiveMboxTimestamp(TestCaseInTempdir):
assert(os.path.exists(self.mbox_name))
new_atime = os.path.getatime(self.mbox_name)
new_mtime = os.path.getmtime(self.mbox_name)
- self.assertEqual(self.mtime, new_mtime)
- self.assertEqual(self.atime, new_atime)
+ self.assertAlmostEqual(self.mtime, new_mtime, utimes_precision)
+ self.assertAlmostEqual(self.atime, new_atime, utimes_precision)
def testOld(self):
"""mbox timestamps should not change after archival"""
@@ -684,8 +687,8 @@ class TestArchiveMboxTimestamp(TestCaseInTempdir):
assert(os.path.exists(self.mbox_name))
new_atime = os.path.getatime(self.mbox_name)
new_mtime = os.path.getmtime(self.mbox_name)
- self.assertEqual(self.mtime, new_mtime)
- self.assertEqual(self.atime, new_atime)
+ self.assertAlmostEqual(self.mtime, new_mtime, utimes_precision)
+ self.assertAlmostEqual(self.atime, new_atime, utimes_precision)
def tearDown(self):
archivemail.options.quiet = 0
The patch applies with some offsets agains the current, official upstream svn
revision 284 (the git repo is not public). --
Speaking as upstream: as development has stalled for quite some time
now, a short note about that may be in order. I'm quite willing to dust
off archivemail development; there is quite a lot of work that went into
the project which is still not published, and it would be sad if that
was all lost. Unfortunately, it will require some very unpleasant
cleanup work to get my git repo in a state where it can be pushed to an
official repo. Still, I am hoping to bring that further along, and
maybe to do a maintenance release in the near future (which should be
much easier to do).
Nikolaus
[1]
http://sourceforge.net/tracker/?func=detail&aid=2043900&group_id=49630&atid=456910
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
