
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:
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]
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".

[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.
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.

[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>.

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.
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

Exactly how does it fail?
[Raymond Hettinger, on bug737473]
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>. ...
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.

On Sun, Oct 31, 2004 at 02:27:18PM -0500, Tim Peters wrote:
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]
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".

[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.
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.

[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>.

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.
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

Exactly how does it fail?
[Raymond Hettinger, on bug737473]
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>. ...
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