Repository navigation
os.getcwd fails for long path names on linux #46974
Description
| BPO | 2722 |
|---|---|
| Nosy | @birkenfeld, @facundobatista, @gpshead, @amauryfa, @giampaolo, @tiran, @smurfix |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-06-22.13:37:12.111>
created_at = <Date 2008-04-30.00:01:51.549>
labels = ['easy', 'library']
title = 'os.getcwd fails for long path names on linux'
updated_at = <Date 2009-09-02.02:59:47.684>
user = 'https://bugs.python.org/exarkun'bugs.python.org fields:
activity = <Date 2009-09-02.02:59:47.684>
actor = 'boya'
assignee = 'none'
closed = True
closed_date = <Date 2008-06-22.13:37:12.111>
closer = 'facundobatista'
components = ['Library (Lib)']
creation = <Date 2008-04-30.00:01:51.549>
creator = 'exarkun'
dependencies = []
files = ['10240', '10241', '10250']
hgrepos = []
issue_num = 2722
keywords = ['patch', 'easy']
message_count = 10.0
messages = ['65987', '66021', '66022', '66370', '66519', '66531', '68563', '92145', '92150', '92152']
nosy_count = 10.0
nosy_names = ['georg.brandl', 'facundobatista', 'gregory.p.smith', 'exarkun', 'amaury.forgeotdarc', 'giampaolo.rodola', 'christian.heimes', 'smurfix', 'nbm', 'boya']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue2722'
versions = ['Python 2.5', 'Python 2.4']
Activity
exarkun commentedon Apr 30, 2008
$ python -c "print len('`pwd`'); import os; print os.getcwd()" 1174 Traceback (most recent call last): File "<string>", line 1, in ? OSError: [Errno 34] Numerical result out of range $The getcwd man page documents the ERANGE failure and suggests that the
calling application allocate a larger buffer and try again.
birkenfeld commentedon Apr 30, 2008
Why isn't the buffer length MAX_PATH anyway?
tiran commentedon Apr 30, 2008
It should be MAX_PATH. All path related functions should use MAX_PATH as
buffer size, maybe even MAX_PATH+1
smurfix commentedon May 7, 2008
MAX_PATH is a compile time constant which, like FD_BITS for select(),
may be too small for the system you're ultimately running on.
Using that as default initial size is OK, but handling ERANGE is still a
very good idea.
nbm commentedon May 10, 2008
This affects OS X too.
I'm attaching two patches - one uses malloc to build a bigger string if
the existing implementation returns ERANGE, and the other one uses
malloc from the start. This was done on the theory that stack memory
use would be better/more efficient. However, based on testing, there's
no real difference - 16.8usec vs. 17usec - on a rarely-used function.
nbm commentedon May 10, 2008
Here's a patch to add a test that fails with Python 2.5 on OS X, but
passes with either of these patches.
facundobatista commentedon Jun 22, 2008
Went for the malloc only patch. Just fixed a small detail (weird corner
case if malloc returned NULL first time, res will be unassigned).
The test could be better (no necessity of using a recursive function, it
could be done with a while), but it works.
Commited in r64452.
boya commentedon Sep 1, 2009
This bug occurred in posix_getcwd() and is being fixed.
Should the following code in posix_getcwdu() also be fixed the same way?
In my opinion, the fixed length buf should be discarded and instead
allocate memory to buf as needed (as the fix code in posix_getcwd()),
since getcwd() does not have a maximum anymore.
amauryfa commentedon Sep 2, 2009
Please open a new issue; and a patch is welcome.
boya commentedon Sep 2, 2009
Amaury,
Created bpo-6817 with a patch.