Current test_shutil is apparently trying to do something that can't work on Windows, so it fails: test_shutil test test_shutil failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_shutil.py", line 28, in test_on_error shutil.rmtree(TESTFN, onerror=self.check_args_to_onerror) File "C:\Code\python\lib\shutil.py", line 168, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "C:\Code\python\lib\test\test_shutil.py", line 36, in check_args_to_onerror self.assertEqual(func, os.remove) AssertionError: <built-in function rmdir> != <built-in function remove> 1 test failed: test_shutil After that, it leaves behind temp directories that cause other tests to fail. Sorry, I've got other problems on my stack, and can't make time for this one.
On Sun, Oct 31, 2004 at 02:27:18PM -0500, Tim Peters wrote:
Current test_shutil is apparently trying to do something that can't work on Windows, so it fails:
test_shutil test test_shutil failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_shutil.py", line 28, in test_on_error shutil.rmtree(TESTFN, onerror=self.check_args_to_onerror) File "C:\Code\python\lib\shutil.py", line 168, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "C:\Code\python\lib\test\test_shutil.py", line 36, in check_args_to_onerror self.assertEqual(func, os.remove) AssertionError: <built-in function rmdir> != <built-in function remove>
1 test failed: test_shutil
Hum, I didn't realize os.chmod() worked this differently on Windows. Seems like I bumped into bug #755617 (os module: Need a better description of "mode"). Per that bug, I googled for '_chmod msdn' and came up with the attached patch. However, I don't have a Windows machine handy to test. Could someone with a Windows machine try the patch? Cheers, Johannes
[Johannes Gijsbers]
Hum, I didn't realize os.chmod() worked this differently on Windows. Seems like I bumped into bug #755617 (os module: Need a better description of "mode"). Per that bug, I googled for '_chmod msdn' and came up with the attached patch. However, I don't have a Windows machine handy to test. Could someone with a Windows machine try the patch?
I'll try it, but there were no attachments. Distinctions among "user", "group" and "world" are unique to Unix. Windows has a much more elaborate permission scheme than that, but at chmod()'s feeble level it's essentially just "nobody can delete me" or "anyone can delete me".
On Sun, Oct 31, 2004 at 04:00:43PM -0500, Tim Peters wrote:
[Johannes Gijsbers]
Hum, I didn't realize os.chmod() worked this differently on Windows. Seems like I bumped into bug #755617 (os module: Need a better description of "mode"). Per that bug, I googled for '_chmod msdn' and came up with the attached patch. However, I don't have a Windows machine handy to test. Could someone with a Windows machine try the patch?
I'll try it, but there were no attachments.
Oops. Here you go. Johannes
[Johannes Gijsbers]
Hum, I didn't realize os.chmod() worked this differently on Windows.
Well, it can't work the same. At the chmod() level, there are no "user", "group" or "world"/"other" concepts on Windows. There also aren't distinct "execute"/"search", "write" and "read" bits. There are "hidden", "system", and "archive" bits on Windows, which have no equivalents on Unix, and there's a "read only" bit on Windows, setting which is kind of like turning off 0222 on Unix. The only thing chmod() is useful for on Windows is fiddling the state of the "read only" bit.
Seems like I bumped into bug #755617 (os module: Need a better description of "mode"). Per that bug, I googled for '_chmod msdn' and came up with the attached patch. However, I don't have a Windows machine handy to test. Could someone with a Windows machine try the patch?
No cigar. The patched test appears to assume that if you strip write permission from a directory, that also makes it impossible to delete files within the directory. But directories on Windows aren't files -- they're directories <wink>. The attached patch allows the test to pass on WinXP, although I'm not sure about Win95/98/ME. If there are no objections, I'll check it in. I don't remember enough about Unix's equally obscure permission gimmicks to be sure that this patch will leave the test working on non-Windows boxes.
On Sun, Oct 31, 2004 at 08:26:33PM -0500, Tim Peters wrote:
The attached patch allows the test to pass on WinXP, although I'm not sure about Win95/98/ME. If there are no objections, I'll check it in. I don't remember enough about Unix's equally obscure permission gimmicks to be sure that this patch will leave the test working on non-Windows boxes.
It works on my Debian machine, so no objections from me. Cheers, Johannes
On Sun, Oct 31, 2004 at 08:26:33PM -0500, Tim Peters wrote:
The attached patch allows the test to pass on WinXP, although I'm not sure about Win95/98/ME. If there are no objections, I'll check it in. I don't remember enough about Unix's equally obscure permission gimmicks to be sure that this patch will leave the test working on non-Windows boxes.
It works on my Debian machine, so no objections from me.
Run fine on WinME. Am still getting a failure for test_traceback.py's test_bug737473. Raymond
[Raymond Hettinger]
Run fine on WinME.
Am still getting a failure for test_traceback.py's test_bug737473.
Fixed that already for WinXP. No current failures in the -uall test suite. Is there a bug report for this ME problem? Exactly how does it fail? Does it work if you force the test to take the time.sleep() path instead of the os.utime() path? Is posixmodule.c's posix_utime() taking the utime() or _wutime() path on ME? If the latter, does it work if you force it to take the utime() path instead? MS docs claim utime() and _wutime() work "under Windows 98/Me and Windows NT/2000/XP", but they could be lying: <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/...> That link has a wonderful C example: if you study the sample output, it shows that the sample code they ran had no visible effect <wink>.
Fixed that already for WinXP. No current failures in the -uall test suite. Is there a bug report for this ME problem? Exactly how does it fail?
Traceback (most recent call last): File "test_traceback.py", line 79, in test_bug737473 test_bug737473.test() File "c:\windows\temp\tmpsj7w5a\test_bug737473.py", line 2, in test ValueError
Does it work if you force the test to take the time.sleep() path instead of the os.utime() path?
Yes.
Is posixmodule.c's posix_utime() taking the utime() or _wutime() path on ME? If the latter, does it work if you force it to take the utime() path instead? MS docs claim utime() and _wutime() work "under Windows 98/Me and Windows NT/2000/XP", but they could be lying:
<http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vclib/html/_crt__utime.2c_._wutime.asp>
That link has a wonderful C example: if you study the sample output, it shows that the sample code they ran had no visible effect <wink>.
Am challenged for time in the next couple of days. Will delve deeper at the first opportunity. For the time being, I think it would be best to use sleep() instead of utime(). While it costs three seconds, at least we know it to be a platform independent test. It is rather late in the game to be debugging OS specific problems introduced by a new check-in. Raymond
On Mon, 1 Nov 2004 01:50:29 -0500, Raymond Hettinger <python@rcn.com> wrote:
For the time being, I think it would be best to use sleep() instead of utime(). While it costs three seconds, at least we know it to be a platform independent test. It is rather late in the game to be debugging OS specific problems introduced by a new check-in.
Okay. I am convinced about using sleep() always. And two seconds will be enough to wait for new timestamp value. :) Will check it in right now. Hye-Shik
Exactly how does it fail?
[Raymond Hettinger, on bug737473]
Traceback (most recent call last): File "test_traceback.py", line 79, in test_bug737473 test_bug737473.test() File "c:\windows\temp\tmpsj7w5a\test_bug737473.py", line 2, in test ValueError
That helps.
Does it work if you force the test to take the time.sleep() path instead of the os.utime() path?
Yes.
Progress <wink>. ...
Am challenged for time in the next couple of days. Will delve deeper at the first opportunity.
For the time being, I think it would be best to use sleep() instead of utime(). While it costs three seconds, at least we know it to be a platform independent test. It is rather late in the game to be debugging OS specific problems introduced by a new check-in.
The checkin isn't that new anymore. Just try changing past = time.time() - 3 to past = time.time() - 6 I added a note to <http://www.python.org/1057992> explaining why that may matter on FAT or FAT32 systems.
participants (4)
-
Hye-Shik Chang -
Johannes Gijsbers -
Raymond Hettinger -
Tim Peters