[issue13261] time.clock () has very low resolution on Linux
New submission from Elijah Merkin : time.clock () has very poor time resolution on Linux (tested on Ubuntu 11.04). The result of call to clock () changes once per several seconds. On the other side, on Windows it provides very good resolution. Here is a doctest that fails on Linux: """ >>> from time import sleep >>> prev = clock () >>> res = True >>> for i in xrange(10): ... sleep(0.15) ... next = clock () ... res = res and (next - prev) > 0.1 ... prev = next >>> print res True """ Currently on Linux I am using a workaround that is attached to the issue. -- components: None files: monotime_unix.py messages: 146347 nosy: ellioh priority: normal severity: normal status: open title: time.clock () has very low resolution on Linux type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file23515/monotime_unix.py ___ Python tracker <http://bugs.python.org/issue13261> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5500] tarfile: path problem in arcname under windows
New submission from Elijah Merkin :
Tested on Python 2.5.4.
1. Use tarfile.open("fname", "w|gz") to create an archive.
2. Add a file using TarFile.add(name, arcname=None, recursive=True,
exclude=None) by specifying 2 params: absolute path to a source file as
'name' and something containing one or more directories, e.g.
'test/myfile.txt' as 'arcname'.
3. Close the archive.
On Linux file is added as 'test/myfile.txt'. On Windows the full path
specified as 'name' is used (e.g. 'D:\\MyDir\\myfile.txt'). When I use
'w|bz2' everything works correctly.
Probably this bug is somewhat similar to a bug #4750, though it happens
under Windows and doesn't happen under Linux.
--
components: Library (Lib), Windows
messages: 83680
nosy: ellioh
severity: normal
status: open
title: tarfile: path problem in arcname under windows
type: behavior
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue5500>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5500] tarfile: path problem in arcname under windows
Elijah Merkin added the comment: Tested again under Python 2.6.1 on Windows XP (added Python 2.6 to versions). An archive I attached to the issue contains a .py file that reproduces the bug and an archive created by it. In my case I just put the .py file to C:\testtarfile\ directory and run it. When I open the file by any archive manager I have in Windows, I see. When I view the file contents in a hex viewer, I also see 'C:\\testtarfile\...', so the problem really exists. However, when uncompressing the archive on Linux (tar -xzf ...) I get 'test/testtarfile.py' as initially expected. The archive is created, and the path in the archive is 'C:\\testtarfile\\testtarfile.py', not 'test/testtarfile.py' as I would expect. -- versions: +Python 2.6 Added file: http://bugs.python.org/file13375/reproduce_issue5500.zip ___ Python tracker <http://bugs.python.org/issue5500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5500] tarfile: path problem in arcname under windows
Elijah Merkin added the comment: Sorry for not explaining properly, I was distracted. 1. The absolute path really exists in the .tar.gz file when I view it in a hex editor. 2. Windows archive managers I tried see that absolute path. 3. Linux tar utility, however, somehow manages to extract the file correctly to the original relative path. That's very strange... -- ___ Python tracker <http://bugs.python.org/issue5500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
