Menu
▾
▴
[ archivemail-Bugs-2043900 ] mtime tests fail with python 2.5
|
From: SourceForge.net <no...@so...> - 2010-08-09 10:48:01
|
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: Closed >Resolution: Fixed 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: 2010-08-09 12:48 Message: Closing all artifacts that are fixed in archivemail 0.8.0. ---------------------------------------------------------------------- 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 |
