[issue9246] os.getcwd() hardcodes max path len

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 s

[issue9246] os.getcwd() hardcodes max path len

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 3.4)

[issue9246] os.getcwd() hardcodes max path len

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

[issue9246] os.getcwd() hardcodes max path len

Changes by William Orr : Removed file: http://bugs.python.org/file39154/max_getcwd.patch ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue9246] os.getcwd() hardcodes max path len

Changes by William Orr : Removed file: http://bugs.python.org/file39005/max_getcwd.patch ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue9246] os.getcwd() hardcodes max path len

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

[issue9246] os.getcwd() hardcodes max path len

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: http://bugs.python.org/file39005/max_getcwd.pat

[issue9246] os.getcwd() hardcodes max path len

Changes by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue9246] os.getcwd() hardcodes max path len

Changes by Zachary Ware : -- nosy: +zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue9246] os.getcwd() hardcodes max path len

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()

[issue9246] os.getcwd() hardcodes max path len

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 ___ __

[issue9246] os.getcwd() hardcodes max path len

Changes by Serhiy Storchaka : -- nosy: +storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue9246] os.getcwd() hardcodes max path len

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue9246] os.getcwd() hardcodes max path len

Antoine Pitrou 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 directory. I don'

[issue9246] os.getcwd() hardcodes max path len

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9246] os.getcwd() hardcodes max path len

Martin v. Löwis 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 current working dir

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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) -- ___

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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: http://bugs.python.org/file22394/os_getcwd

[issue9246] os.getcwd() hardcodes max path len

Changes by Terry J. Reedy : -- versions: +Python 3.3 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9246] os.getcwd() hardcodes max path len

Stefan Krah 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 anyone used them in practice. A

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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 compile-time constant; furt

[issue9246] os.getcwd() hardcodes max path len

Changes by STINNER Victor : Removed file: http://bugs.python.org/file18169/os_getcwd_buffer.patch ___ Python tracker ___ ___ Python-bugs-list m

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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 ___ Python tracker

[issue9246] os.getcwd() hardcodes max path len

Antoine Pitrou 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 pydebug? In this c

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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 has better checks when compi

[issue9246] os.getcwd() hardcodes max path len

STINNER Victor 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. 1028 is bigger than 1026 (pr

[issue9246] os.getcwd() hardcodes max path len

Stefan Krah added the comment: Terry J. Reedy wrote: > mkdir: 242 > Traceback (most recent call last): > File "C:\Programs\Python31\misc\t1.py", line 14, in > os.mkdir(s) > WindowsError: [Error 206] The filename or extension is too long: > 'C:\\Programs\\Python31\\misc\\ab\\ab\\

[issue9246] os.getcwd() hardcodes max path len

Terry J. Reedy 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 os.mkdir(s) WindowsError: [Error 206] The filename or extension is too long: 'C:\\Programs\\Python31\\misc\\ab\\ab\\ab\

[issue9246] os.getcwd() hardcodes max path len

Stefan Krah added the comment: Closed issue 6817 as a duplicate of this one. There are some patches in that issue. -- nosy: +boya ___ Python tracker ___ _

[issue9246] os.getcwd() hardcodes max path len

Changes by R. David Murray : -- priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue9246] os.getcwd() hardcodes max path len

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

[issue9246] os.getcwd() hardcodes max path len

Stefan Krah 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 ___ __

[issue9246] os.getcwd() hardcodes max path len

Antoine Pitrou 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 getcwd() in a path l

[issue9246] os.getcwd() hardcodes max path len

New submission from Antoine Pitrou : 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 length is larg