[issue10608] [doc] Add a section to Windows FAQ explaining os.symlink

Eryk Sun added the comment: Ingrid's patch misses the requirement to log off after adding a privilege to the current account. A new access token is required, from a fresh logon. Privileges can also be added to groups, not just to individual user accounts. Thus the symlink privilege can be

[issue10608] [doc] Add a section to Windows FAQ explaining os.symlink

Change by Irit Katriel : -- title: Add a section to Windows FAQ explaining os.symlink -> [doc] Add a section to Windows FAQ explaining os.symlink type: behavior -> enhancement versions: +Python 3.11 -Python 2.7, Python 3.4, Python 3.5 ___

[issue44837] os.symlink arg names are bad

Steven D'Aprano added the comment: On Thu, Aug 05, 2021 at 12:00:31PM +, krey wrote: > @steven.daprano My suggestion was changing the names of the args, not the > order > > Current > def os.symlink(src, dst): > ln -s src dst So far so good. > Changing the n

[issue44837] os.symlink arg names are bad

Steven D'Aprano added the comment: There is no one single set of names used by `ln` that we could have chosen. Any choice we made would have annoyed some people. I strongly argue that, of all the various naming conventions in common usage (see below), Python's choice of src, dest (source,

[issue44837] os.symlink arg names are bad

Current def os.symlink(src, dst): ln -s src dst Changing the names def os.symlink(dst, src): ln -s dst src Changing the order def os.symlink(dst, src): ln -s src dst I concede that different unixes have different argnames for ln, it's a bit of a mess. From a CS theory perspective, I

[issue44837] os.symlink arg names are bad

Eric V. Smith added the comment: There's really no way we'd consider breaking possibly millions of working programs to change the parameter names. I guess you could come up with some way of supporting both sets of parameter names, but I doubt we'd accept that, either. While maybe in

[issue44837] os.symlink arg names are bad

this change. But it is vanishingly unlikely that we would change either the names of the parameters, or their order, without a really good reason. You haven't given us any convincing justification for why we should make this change. The os.symlink function takes its arguments in exactly the same order

[issue44837] os.symlink arg names are bad

krey added the comment: @eric.smith Sorry for tagging this as docs, wasn't sure what to pick. I guess it should be under Library Does CPython have a process for changing arg names via deprecation warnings? -- ___ Python tracker

[issue44837] os.symlink arg names are bad

Eric V. Smith added the comment: @krey: What's your suggested change? We can change neither the parameter order nor parameter names without breaking code, so that won't happen. You created this as a documentation issue. Do you have a suggested documentation change? -- nosy:

[issue44837] os.symlink arg names are bad

Steven D'Aprano added the comment: Order of arguments for ln: ln -s SOURCE DESTINATION Order of arguments for os.symlink: os.symlink(SOURCE, DESTINATION) They are exactly the same order. > Everywhere else I've seen, arrows (or directed edges in a graph) point as > SOURCE -&g

[issue44837] os.symlink arg names are bad

egory_(mathematics)#Definition ln has two arguments, LINKNAME and TARGET, so it's implied that LINKNAME -> TARGET In fact that's exactly what you see visually when you run ls -l In os.symlink, however, you have SRC <- DST which is weird. I agree that this weirdness is explained in grammatically cor

[issue44837] os.symlink arg names are bad

stack for needle os.symlink(src, dst) -> create symlink pointing to source called dst -> or create symlink called dst pointing to src The order of arguments is the same as for ln: ln [OPTION]... [-T] TARGET LINK_NAME TARGET is src, LINK_NAME is dst. I don't think that th

[issue44837] os.symlink arg names are bad

New submission from krey : From: https://docs.python.org/3/library/os.html os.symlink(src, dst, target_is_directory=False, *, dir_fd=None) Create a symbolic link pointing to `src` named `dst`. It's a bit like saying find(needle, haystack) Finds `haystack` in `needle` If you look

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Change by Barney Gale : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue36656] Add race-free os.link and os.symlink wrapper / helper

Change by Yonatan Goldschmidt : -- nosy: +Yonatan Goldschmidt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29657] os.symlink: FileExistsError shows wrong message

Yonatan Goldschmidt added the comment: Just reached this issue independently (spent a few minutes debugging an error message like "FileExistsError: [Errno 17] File exists: 'a' -> 'b'", where 'a' didn't exist...) I agree with Rich on this - for me, the source of confusion was that the way

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Steve Dower added the comment: New changeset b57e045320d1d2a70eab236b7d31a3ebb75037c3 by Barney Gale in branch 'master': bpo-39924: handle missing os functions more consistently in pathlib (GH-19220) https://github.com/python/cpython/commit/b57e045320d1d2a70eab236b7d31a3ebb75037c3

[issue29657] os.symlink: FileExistsError shows wrong message

Change by Kamil Turek : -- nosy: +kamilturek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29657] os.symlink: FileExistsError shows wrong message

Change by Eryk Sun : -- components: +Extension Modules, Interpreter Core -Library (Lib) stage: patch review -> versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7 ___ Python tracker

[issue36656] Add race-free os.link and os.symlink wrapper / helper

Tom Hale added the comment: Related issue found in testing: bpo-42778 Add follow_symlinks=True parameter to both os.path.samefile() and Path.samefile() -- ___ Python tracker

[issue36656] Add race-free os.link and os.symlink wrapper / helper

Tom Hale added the comment: Related: bpo-41134 distutils.dir_util.copy_tree FileExistsError when updating symlinks WIP update: I am just about to ask for feedback on my proposed solution at core-mentors...@python.org -- title: Please add race-free os.link and os.symlink wrapper

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Change by Barney Gale : -- pull_requests: +18582 pull_request: https://github.com/python/cpython/pull/19220 ___ Python tracker ___

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Change by Manjusaka : -- keywords: +patch pull_requests: +18345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18998 ___ Python tracker ___

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Barney Gale added the comment: Good points! Do you know of an example of a community library that uses `_Accessor.link`? Thanks -- ___ Python tracker ___

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Manjusaka added the comment: Fine, I get your means -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Manjusaka added the comment: But when will os.readlink() be unavailable? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

Manjusaka added the comment: I don't think rename 'link_to' to 'link' directly is a good idea. Because there are many third-party libs have used this name. Unless we can keep two names in this version, and remind people the 'link_to' function will be deprecated totally in a future version.

[issue39924] pathlib handles missing `os.link`, `os.symlink` and `os.readlink` inconsistently

New submission from Barney Gale : Small bug report encompassing some related issues in `pathlib._NormalAccessor`: - `link_to()` should be named `link()` for consistency with other methods - `symlink()` doesn't need to guard against `os.symlink()` not accepting `target_is_directory` on non

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Tom Hale added the comment: I've created a PR here: https://github.com/python/cpython/pull/14464 Only shutil.symlink is currently implemented. Feedback sought from Windows users. @Michael.Felt please note that `overwrite=False` is the default. @taleinat I hope that the new implementation

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Change by Roundup Robot : -- keywords: +patch pull_requests: +14280 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14464 ___ Python tracker ___

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Tal Einat added the comment: I think there is a general flaw with the suggested implementation approach. An infinite loop as currently suggested seems dangerous to me. For example, it could cause a program to stall indefinitely in some unforeseen edge-case. I don't think this would be

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Change by Tal Einat : -- components: +Library (Lib) versions: +Python 3.9 -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Michael Felt added the comment: I started a reply on the python-mentoring maillist - and promised to come back here. a) imho - the discussion about an "attacker" is only misleading for the general case. For active attacks - where an attacker has active acces to the system is not something

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Robert Collins added the comment: Thank you @Eryk -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Change by Michael Felt : -- nosy: +Michael.Felt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

Eryk Sun added the comment: > I'd like to add a few notes; please do consider Windows interactions > here - Windows does not have the same model for inode replacement that > Posix has. Certainly Windows doesn't have the same model for inode replacement since it doesn't have inodes. ;-)

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

on PyPI that provides the secure behaviour necessary, get some feedback on that, get some cross-platform experience, and then, if desired, propose it for inclusion in shutil or similar in the stdlib. I'm also going to retitle this - because actually, os.link and os.symlink aren't racy *per se

[issue36656] Race conditions due to os.link and os.symlink POSIX specification

ems programmers who will realise that there is a sometimes-occurring exception which should be handled. So most people won't handle it. They don't know that they need to. The shutil os.link and os.symlink wrappers under discussion on python-ideas prevent non-system-programmers from needing to k

[issue36656] Race conditions due to os.link and os.symlink POSIX specification

Change by Tom Hale : -- title: Allow os.symlink(src, target, force=True) to prevent race conditions -> Race conditions due to os.link and os.symlink POSIX specification ___ Python tracker <https://bugs.python.org/issu

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Change by Tom Hale : -- type: security -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Tom Hale added the comment: Thanks Toshio Kuratomi, I raised it on the mailing list at: https://code.activestate.com/lists/python-ideas/55992/ -- ___ Python tracker ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Change by Ned Deily : -- Removed message: https://bugs.python.org/msg342103 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Ned Deily added the comment: New changeset 77c02cdce2d7b8360771be35b7676a4977e070c1 by larryhastings (Steve Dower) in branch '3.4': [3.4] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (#5992) https://github.com/python/cpython/commit/77c02cdce2d7b8360771be35b7676a4977e070c1

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Toshio Kuratomi added the comment: Additionally, the os module is supposed to closely follow the behaviour of the underlying operating system functions: https://docs.python.org/3/library/os.html > The design of all built-in operating system dependent modules of Python is > such that as

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Serhiy Storchaka added the comment: So what? Detected problem is better than non-detected problem. If and unexpected exception causes troubles in your code, it is up to you what to do with it: silence it, terminate an application, try to recreate a symlink in other place, etc. In any case

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Tom Hale added the comment: Yes, but by default (because of difficulty) people won't check for this case: 1. I delete existing symlink in order to recreate it 2. Attacker watching symlink finds it deleted and recreates it 3. I try to create symlink, and an unexpected exception is raised

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

Serhiy Storchaka added the comment: If the symlink can be recreated, it can also be changed after creation. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

if it exists. ''' # os.replace may fail if files are on different filesystems. # Therefore, use the directory of target link_dir = os.path.dirname(target) # os.symlink requires that the target does NOT exist. # Avoid race condition of file creation

[issue36656] Allow os.symlink(src, target, force=True) to prevent race conditions

New submission from Tom Hale : I cannot find a race-condition-free way to force overwrite an existing symlink. os.symlink() requires that the target does not exist, meaning that it could be created via race condition the two workaround solutions that I've seen: 1. Unlink existing symlink

[issue35367] FileExistsError During os.symlink() Displays Arrow in the Wrong Direction

Change by Windson Yang : -- pull_requests: +10373 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29657] os.symlink: FileExistsError shows wrong message

Rich Jones added the comment: @Larry - that would be an acceptable solution! I'm here because I encountered this error independently. I explain why the arrow is a problem here: https://bugs.python.org/issue35367 The issue is that the '->' notation is already used by the standard operating

[issue35367] FileExistsError During os.symlink() Displays Arrow in the Wrong Direction

Change by Eryk Sun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> os.symlink: FileExistsError shows wrong message ___ Python tracker <https://bugs.python

[issue35367] FileExistsError During os.symlink() Displays Arrow in the Wrong Direction

, Jul 23 2018, 20:22:55) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.symlink('HELLO.txt', 'GOODBYE.txt') $ ls -lah * lrwxr-xr-x 1 rjones staff 9B

[issue33946] os.symlink on Windows should use the new non-admin flag

Change by Eryk Sun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add non-elevated symlink support for dev mode Windows 10 type: -> enhancement ___ Python tracker

[issue33946] os.symlink on Windows should use the new non-admin flag

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33946] os.symlink on Windows should use the new non-admin flag

: normal status: open title: os.symlink on Windows should use the new non-admin flag ___ Python tracker <https://bugs.python.org/issue33946> ___ ___ Python-bugs-list mailin

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Steve Dower added the comment: Thanks Larry for merging the backports! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Larry Hastings <la...@hastings.org> added the comment: New changeset f381cfe07d15d52f27de771a62a8167668f0dd51 by larryhastings (Steve Dower) in branch '3.5': [3.5] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (#5991) https://github.com/python/cpython/

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Larry Hastings <la...@hastings.org> added the comment: New changeset 77c02cdce2d7b8360771be35b7676a4977e070c1 by larryhastings (Steve Dower) in branch '3.4': [3.4] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (#5992) https://github.com/python/cpython/

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Steve Dower added the comment: Thanks, Victor! -- ___ Python tracker ___ ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

STINNER Victor added the comment: FYI I added this vulnerability to: http://python-security.readthedocs.io/vuln/cve-2018-1000117_buffer_overflow_vulnerability_in_os.symlink_on_windows.html

[issue33001] Buffer overflow vulnerability in os.symlink on Windows (CVE-2018-1000117)

Steve Dower <steve.do...@python.org> added the comment: FYI, the CVE number for this issue is CVE-2018-1000117. -- title: Buffer overflow vulnerability in os.symlink on Windows -> Buffer overflow vulnerability in os.symlink on Windows (CVE-201

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

miss-islington <mariatta.wijaya+miss-isling...@gmail.com> added the comment: New changeset 96fdbacb7797a564249fd59ccf86ec153c4bb095 by Miss Islington (bot) in branch '3.7': bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) https://github.com/python/cpython/

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Steve Dower added the comment: Patches are merged, except for the ones that belong to @Larry. Thanks again Alexey for the final round of feedback! -- nosy: +larry ___ Python tracker

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Change by miss-islington : -- pull_requests: +5762 ___ Python tracker ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Steve Dower <steve.do...@python.org> added the comment: New changeset baa45079466eda1f5636a6d13f3a60c2c00fdcd3 by Steve Dower in branch '3.6': [3.6] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (GH-5990) https://github.com/python/cpython/

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Steve Dower <steve.do...@python.org> added the comment: New changeset 6921e73e33edc3c61bc2d78ed558eaa22a89a564 by Steve Dower in branch 'master': bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) https://github.com/python/cpython/commit/6921e73e33edc3c61bc2d78ed558eaa22a

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Eryk Sun <eryk...@gmail.com> added the comment: >> As os.symlink requires administrative privileges on most versions >> of Windows > > The current implementation requires SeCreateSymbolicLinkPrivilege on > ALL versions of Windows because users m

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Alexey Izbyshev <izbys...@ispras.ru> added the comment: > As os.symlink requires administrative privileges on most versions of Windows The current implementation requires SeCreateSymbolicLinkPrivilege on ALL versions of Windows because users must pass an additional flag to CreateSym

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

"help", "copyright", "credits" or "license" for more information. >>> import os >>> os.symlink(b'x\\' * 129, b'y\\' * 129) (Windows pop-up here) -- ___ Python trac

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Change by Steve Dower : -- pull_requests: +5759 ___ Python tracker ___ ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Change by Steve Dower : -- pull_requests: +5758 ___ Python tracker ___ ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Change by Steve Dower : -- pull_requests: +5757 ___ Python tracker ___ ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

Change by Steve Dower : -- keywords: +patch pull_requests: +5756 stage: -> patch review ___ Python tracker ___

[issue33001] Buffer overflow vulnerability in os.symlink on Windows

New submission from Steve Dower <steve.do...@python.org>: On February 27th, 2018, the Python Security Response team was notified of a buffer overflow issue in the os.symlink() method on Windows. The issue affects all versions of Python between 3.2 and 3.6.4, including the 3.7 beta re

[issue29657] os.symlink: FileExistsError shows wrong message

d "dst" in the error message only when the error pertains to os.symlink. If literally every time the two-filename version of OSError is used inside Python, the two filenames are "src" and "dst", then we could consider making it slightly more explicit, e.g. Fil

[issue29657] os.symlink: FileExistsError shows wrong message

Serhiy Storchaka added the comment: See issue20517 for the discussion about current implementation. Are there any ideas about clearer error messages? Added Larry as the author of the original idea and implementation. -- nosy: +larry ___ Python

[issue29657] os.symlink: FileExistsError shows wrong message

Xiang Zhang added the comment: I agree with Eryk. The error message is misleading. When I see it, I take it as source -> destination. I think we should make the error message clearer, or document it in the OSError documentation. -- ___ Python

[issue29657] os.symlink: FileExistsError shows wrong message

Eryk Sun added the comment: To me the error message is in the model of a source -> destination operation, in which the arrow indicates the operation's information flow (e.g. of the target path or inode number) from the source file to the destination file. I've never viewed it superficially as

[issue29657] os.symlink: FileExistsError shows wrong message

Serhiy Storchaka added the comment: This is not about how a symbolic link is represented. This is about how the operation of creating a symbolic link is represented. The first filename is the first argument of os.symlink(), the second filename is the second argument. Try to run

[issue29657] os.symlink: FileExistsError shows wrong message

Eryk Sun added the comment: A symbolic link is typically represented the other way around, from the point of view of the link pointing at the target. However, Python conceptualizes linking as something like a copy or rename operation, with source and destination filenames, and the current

[issue29657] os.symlink: FileExistsError shows wrong message

Serhiy Storchaka added the comment: The current error message looks good to me. What is wrong with it? -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue29657] os.symlink: FileExistsError shows wrong message

Changes by Terry J. Reedy : -- stage: -> patch review type: -> behavior ___ Python tracker ___

[issue29657] os.symlink: FileExistsError shows wrong message

Andrew Nester added the comment: I've been investigating this issue and did not come up with some easy solution. So the problem is: os_symlink uses `path_error2` to throw exception. the order of file arguments now is src then dest. For provided example src is `a` and dest is `sym_link`. As a

[issue29657] os.symlink: FileExistsError shows wrong message

Changes by Sayan Chowdhury : -- nosy: +sayanchowdhury ___ Python tracker ___

[issue29657] os.symlink: FileExistsError shows wrong message

Xiang Zhang added the comment: I concur the current message is misleading. OSError makes the string "file1 -> file2". This also affects other methods calling `path_error2()` such as os.link(). -- nosy: +xiang.zhang versions: +Python 3.6, Python 3.7

[issue29657] os.symlink: FileExistsError shows wrong message

1 nosy: wrohdewald priority: normal severity: normal status: open title: os.symlink: FileExistsError shows wrong message versions: Python 3.5 Added file: http://bugs.python.org/file46671/x.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue10608] Add a section to Windows FAQ explaining os.symlink

ingrid added the comment: I tried writing a section aimed at beginners, please let me know if you think any information should be added or removed. -- keywords: +patch nosy: +ingrid, jesstess Added file: http://bugs.python.org/file36364/issue10608.patch

[issue10608] Add a section to Windows FAQ explaining os.symlink

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10608 ___

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Georg Brandl added the comment: No change for 3.3. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16074 ___

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Larry Hastings added the comment: It's fine that we're not fixing this in 3.3, but since this did get fixed in 3.4, I propose dropping 3.3 from the version list and changing the resolution to fixed. *waves magic wand* -- resolution: wont fix - fixed stage: needs patch -

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Vajrasky Kok added the comment: Now, that we have fixed this bug in Python 3.4 with this commit http://hg.python.org/cpython/rev/081a9d8ba3c7, what should we do with the bug in Python 3.3? Use my patch (omitting filenames)? Keep the status quo (one filename)? If yes, close this ticket as

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Larry Hastings added the comment: I probably should have continued with this issue instead of creating a new issue for it, sorry. But there's a new issue tracking this change, where I propose to add new error-reporting functions that support two filenames. That's happening in #20517.

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Larry Hastings added the comment: As release manager, I would be willing to consider this patch. However, as original author of the code in question, I don't like it. Showing zero filenames, while potentially less confusing, is also far less helpful. A better solution would be to show both

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Serhiy Storchaka added the comment: However it is still a bug in 3.3. -- assignee: serhiy.storchaka - larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16074 ___

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Serhiy Storchaka added the comment: Larry, are you agree with this solution (remove ambiguous filename attribute from OSError raised by functions with two filename arguments)? -- ___ Python tracker rep...@bugs.python.org

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Serhiy Storchaka added the comment: The 3.4 patch LGTM, but the 3.3 patch perhaps has a bug. -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16074 ___

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Vajrasky Kok added the comment: Jakub Wilk, yeah, I missed that one. Jason Gerard DeRose, thanks for the additional information. Anyway, I already persuaded Ruby developers to specialize the message, although it's only for creating symlink. https://bugs.ruby-lang.org/issues/9263 As of

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Jason Gerard DeRose added the comment: vajrasky, one more errno to consider: [Errno 39] Directory not empty: '/tmp/bar' This is when renaming a directory: src directory exists; dst directory exists and is non-empty. In 3.4 Beta1, this error message now includes the src instead of the dst

[issue16074] Bad error message in os.rename, os.link, and os.symlink

Jakub Wilk added the comment: As far as rename() and link() are concerned, either of the arguments can cause an ENOENT error: os.rename('/dev/foobar', '/dev/barfoo') # fails because /dev/foobar doesn't exist os.rename('/dev/null', '/foo/bar/baz') # fails because /foo/bar doesn't exist

  1   2   3   4   >