Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

os.getcwd fails for long path names on linux #46974

Closed
exarkun mannequin opened this issue Apr 30, 2008 · 10 comments
Closed

os.getcwd fails for long path names on linux #46974

exarkun mannequin opened this issue Apr 30, 2008 · 10 comments
Labels
easy stdlib Python modules in the Lib dir

Comments

@exarkun
Copy link
Mannequin

exarkun mannequin commented Apr 30, 2008

BPO 2722
Nosy @birkenfeld, @facundobatista, @gpshead, @amauryfa, @giampaolo, @tiran, @smurfix
Files
  • python-getcwd-dual-strategy.patch: Patch for stack/malloc dual strategy for getcwd
  • python-getcwd-malloconly.patch: Patch for using malloc exclusively with getcwd
  • python-getcwd-test_longpathnames.patch: Patch to add a test for long path names with getcwd
    		•

    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']
    @exarkun
    Copy link
    Mannequin Author

    exarkun mannequin commented 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.

    @exarkun exarkun mannequin added the stdlib Python modules in the Lib dir label Apr 30, 2008
    @birkenfeld
    Copy link
    Member

    Why isn't the buffer length MAX_PATH anyway?

    @tiran
    Copy link
    Member

    tiran commented Apr 30, 2008

    It should be MAX_PATH. All path related functions should use MAX_PATH as
    buffer size, maybe even MAX_PATH+1

    @gpshead gpshead added the easy label May 2, 2008
    @smurfix
    Copy link
    Mannequin

    smurfix mannequin commented 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
    Copy link
    Mannequin

    nbm mannequin commented 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
    Copy link
    Mannequin

    nbm mannequin commented 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
    Copy link
    Member

    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
    Copy link
    Mannequin

    boya mannequin commented 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?

    posix_getcwdu(PyObject *self, PyObject *noargs)
{
	char buf[1026];
        ...
#if defined(PYOS_OS2) && defined(PYCC_GCC)
	res = _getcwd2(buf, sizeof buf);
#else
	res = getcwd(buf, sizeof buf);
#endif
        ...
}

    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
    Copy link
    Member

    amauryfa commented Sep 2, 2009

    Please open a new issue; and a patch is welcome.

    @boya
    Copy link
    Mannequin

    boya mannequin commented Sep 2, 2009

    Amaury,

    Created bpo-6817 with a patch.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    easy stdlib Python modules in the Lib dir
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    5 participants
    @gpshead @birkenfeld @facundobatista @tiran @amauryfa