STINNER Victor added the comment:
I've updated the patch with the comments from the review
Thanks William for your contribution, I commited your fix.
I just made a minor change on if (cwd use_bytes) {: you forgot to remove
test now useless test on cwd, and I dropped { and } to make to short
Roundup Robot added the comment:
New changeset abf1f3ae4fa8 by Victor Stinner in branch '3.4':
Issue #9246: On POSIX, os.getcwd() now supports paths longer than 1025 bytes
https://hg.python.org/cpython/rev/abf1f3ae4fa8
New changeset b871ace5c58f by Victor Stinner in branch 'default':
(Merge
Changes by William Orr w...@worrbase.com:
Removed file: http://bugs.python.org/file39005/max_getcwd.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
Changes by William Orr w...@worrbase.com:
Removed file: http://bugs.python.org/file39154/max_getcwd.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
William Orr added the comment:
I've updated the patch with the comments from the review
--
Added file: http://bugs.python.org/file39199/max_getcwd.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
William Orr added the comment:
I've incorporated some of the feedback from the reviews into this new patch. I
used the PyMem_Raw* functions to do allocation to avoid having to acquire the
GIL and also avoid complciations from the builtin memory allocator, since I'm
not using python objects.
William Orr added the comment:
Revisiting this, I've updated python3 to calculate this and use gradual dynamic
allocation like the python2 implementation.
--
nosy: +worr
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3
Added file:
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
Python-bugs-list
Changes by Zachary Ware zachary.w...@gmail.com:
--
nosy: +zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
Python-bugs-list
STINNER Victor added the comment:
For the record, os.getcwd() of Python 2 was improved by 96adf96d861a (issue
#2722) to use a dynamic buffer.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
STINNER Victor added the comment:
test_posix.py of Python 3 contains the test, but the test is disabled (dead
code):
def test_getcwd_long_pathnames(self):
if hasattr(posix, 'getcwd'):
dirname = 'getcwd-test-directory-0123456789abcdef-01234567890abcdef'
curdir = os.getcwd()
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
Python-bugs-list
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Simpler patch replacing 1026 constant by MAXPATHLEN. On my Linux box,
MAXPATHLEN is 4096 and os.pathconf('/', 'PC_PATH_MAX') returns 4096. I am able
to get a path of 4095 bytes using the patch.
--
Added file:
STINNER Victor victor.stin...@haypocalc.com added the comment:
You may use get_current_dir_name() which allocates the memory for us.
I can adapt os_getcwd_buffer-2.patch to support Solaris/OpenBSD, but do we need
a dynamic buffer? (do we need to support OS without PATH_MAX)
--
STINNER Victor victor.stin...@haypocalc.com added the comment:
bigpath2.py: script to check the maximum path length of os.getcwd().
--
Added file: http://bugs.python.org/file22395/bigpath2.py
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
I can adapt os_getcwd_buffer-2.patch to support Solaris/OpenBSD, but
do we need a dynamic buffer? (do we need to support OS without
PATH_MAX)
From a practicality point of view, we need to make no change at all:
nobody sane ever has a
Changes by Santoso Wijaya santoso.wij...@gmail.com:
--
nosy: +santa4nt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
From a practicality point of view, we need to make no change at all:
nobody sane ever has a current working directory path of more than
1000 characters. Even if people have very long path names, they
don't make them the current working
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.3 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Antoine asked me why not using a buffer of MAX_PATH+1 (instead of a dynamic
buffer size). I don't know, I just copied/pasted the code from Python2. Extract
of getcwd() manpage:
Note that on some systems, PATH_MAX may not be a
Stefan Krah stefan-use...@bytereef.org added the comment:
For 2.x, unlimited path lengths were apparently introduced in issue 2722.
This strategy does not work on Solaris and OpenBSD (issue 9185).
FreeBSD also seems to support arbitrarily long paths. I would be somewhat
surprised though if
Antoine Pitrou pit...@free.fr added the comment:
It's not ok to call PyMem_* functions when the GIL is released. You should only
release the GIL around the call to the system getcwd().
I suppose that Python has a faster memory allocator, or that it has
better checks when compiled with
STINNER Victor victor.stin...@haypocalc.com added the comment:
New version of the patch avoiding PyMem_*() functions to avoid a possible race
condition (issue with the GIL).
--
Added file: http://bugs.python.org/file18225/os_getcwd_buffer-2.patch
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file18169/os_getcwd_buffer.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
Terry J. Reedy tjre...@udel.edu added the comment:
On WinXP, 3.1, I get
...
mkdir: 242
Traceback (most recent call last):
File C:\Programs\Python31\misc\t1.py, line 14, in module
os.mkdir(s)
WindowsError: [Error 206] The filename or extension is too long:
Stefan Krah stefan-use...@bytereef.org added the comment:
Terry J. Reedy rep...@bugs.python.org wrote:
mkdir: 242
Traceback (most recent call last):
File C:\Programs\Python31\misc\t1.py, line 14, in module
os.mkdir(s)
WindowsError: [Error 206] The filename or extension is too long:
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch based on Python 2 source code, but raises a MemoryError (instead of an
OSError) on memory allocation failure.
With my patch, bigpath.py ends with cwd: 1028 ...aab/ab with Python
Python 3.2. Same result with Python 2.6.
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm not sure that PyMem_Realloc(NULL, size) is always equivalent to
PyMem_Malloc(size). And I don't really know why I'm using PyMem_* instead of
malloc() / free() :-) I suppose that Python has a faster memory allocator, or
that it
Stefan Krah stefan-use...@bytereef.org added the comment:
Closed issue 6817 as a duplicate of this one. There are some patches in
that issue.
--
nosy: +boya
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
New submission from Antoine Pitrou pit...@free.fr:
In 2.x, os.getcwd() uses a dynamic allocation scheme to accomodate whatever
buffer size the current path needs to be represented.
In 3.x, the max path length is hardcoded to 1026 bytes or characters, and an
error is raised if the current path
Antoine Pitrou pit...@free.fr added the comment:
Even on systems where MAX_PATH is 1024 (a common value), it is still
valid to create paths larger than that (using e.g. os.mkdir()).
It seems I am mistaken on that. MAX_PATH is actually 4096 on the Linux system I
am testing on. Calling
Stefan Krah stefan-use...@bytereef.org added the comment:
Just as a reminder: In 2.x, posix_getcwdu() also uses a buffer of size
1026.
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
Antoine Pitrou pit...@free.fr added the comment:
Just as a reminder: In 2.x, posix_getcwdu() also uses a buffer of size
1026.
I suppose the implementation was simply copied into py3k, then.
Still, it's not a very good idea and it will also be a regression when
porting scripts from 2.x to 3.x.
Changes by R. David Murray rdmur...@bitdance.com:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9246
___
___
35 matches
Mail list logo
