I've been using 3.3.0b1 for development, with mostly no problems, but today I was surprised and confused by an error message. It is an attempt to be an improvement over 3.2, giving the filename that os.rename cannot find... but instead, it gives the one it is renaming to.

So I quickly upgraded to 3.3.0rc3, and it contains the same error.

Could you give a specific example of the message you got, why it is wrong, and what you think it should be?
Is there any reason to think that this is Windows-specific?

I confirm the bug.

>>> import os
>>> os.rename('non-existent-name', 'new-name')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'new-name'

It obviously should be "No such file or directory: 'non-existent-name'".

Error in argument of path_error in function internal_rename.

For some errcode it should be dst, for some src, for some both, for some none, and for some it is unknown. And this can be platform-specific.

I suggest rollback this enhancement.

> Error in argument of path_error in function internal_rename.

In file Modules/posixmodule.c.

Terry, I thought the test case would demonstrate the error details.
As far as Windows, I encountered it there, and it seemed like the sort of error that could be in a Windows-specific module.

Serhiy, thanks for confirming, and analyzing. At this point in the release cycle, rolling back the enhanced message is probably better than trying to fix it.  The 3.2 message was imprecise, but not confused with the sometimes-wrong file name.

Now the printing the source name instead of the destination as the bug described.

Just for record the same issue can be seen in a Linux box also. I tested in a Fedora 17 system.

As Serhiy says, which filename to display is wholly context-sensitive to which errno it is.  And there's no cheap way to display both.  The cheap fix is to call path_error with a nulled-out "path" object; this will display the error without a filename.

Patch doing this attached.

By default we can't fix this in 3.3.0.  I'll add Georg on the off chance he wants to cherry-pick it.

Perhaps for 3.3.1 I can fix this properly, with a switch on the errno.

New patch, just calling posix_error directly.

Same issue for os.link and os.symlink.

>>> import os
>>> os.link('non-existent-name', 'new-name')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'new-name'
>>> os.symlink('long-name'*1000, 'new-name')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 36] File name too long: 'new-name'

As I see, now 3.4 behavior differs from 3.3 behavior.

>>> os.link('non-existent-name', 'new-name')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: 'non-existent-name'
>>> os.symlink('long-name'*1000, 'new-name')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 36] File name too long: 'long-namelong-namelong-namelong-namelong-namelong-name...

I just closed two almost identical issues in favour of this issue. I believe that in order to avoid ambiguity, there are three possible solutions of such issues:

1. Do not display any filename (as in Python 2.7).
2. Display both filenames (this can also be slightly ambiguous).
3. Depending on the errno display the first filename or the second filename, or neither, or both.

I would say either option 3, or, if it's too complicated, option 2.
FTR the two issues mentioned in the previous message are #13775 and #16812.

Here is the patch for Python 3.4. It removed file information for os.rename, os.link, and os.symlink.

I agree with Ezio that giving extra information is better but since Python 3.4 is in beta.... maybe we can defer this to Python 3.5.

There are couples of errno that need extra information. For example, in Linux:
[Errno 2] No such file or directory -> source
[Errno 17] File exists -> destination
[Errno 36] Filename too long -> tough to decide, can be source, can be destination
[Errno 27] File too large -> source
Anything left?

Patch for Python 3.3. It omitted file information for error messages in rename, symlink, and link.

I'll create a separate ticket for adding extra file information to these error messages.

Is there any possibility this ticket could be committed in Python 3.4? If yes, it would be good because we would have a good foundation for creating better error message in Python 3.5.

Anyway, I check Python's competitors' behaviour.

Ruby displays both files.

irb(main):001:0> File.symlink('a.txt', 'b')
Errno::EEXIST: File exists @ sys_fail2 - (a.txt, b)
	from (irb):1:in `symlink'
	from (irb):1
	from /home/ethan/Documents/code/ruby/localruby/bin/irb:11:in `<main>'

Perl omits the files.

  DB<8> print symlink("a.txt", "b");
0
  DB<9> print $!;
File exists

PHP omits the files.

php -r "symlink('b', 'a');"
PHP Warning:  symlink(): File exists in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP   2. symlink() Command line code:1

Warning: symlink(): File exists in Command line code on line 1

Call Stack:
    0.0001     225688   1. {main}() Command line code:0
    0.0001     226392   2. symlink() Command line code:1

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

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 (flipped behaviour from Python 3.3). I'm not sure whether this changed because of changes being tracked in this bug on not, so I filed a separate issue: http://bugs.python.org/issue20093

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 Python, let's leave that for Python 3.5.

The 3.4 patch LGTM, but the 3.3 patch perhaps has a bug.

Larry, are you agree with this solution (remove ambiguous filename attribute from OSError raised by functions with two filename arguments)?

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 filenames.  This would require changing the OSError exception, and adding some new PyErr_ API calls.  I'm now working on a patch to do that.

However it is still a bug in 3.3.

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.

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

Backport Larry's commit (two filenames) which is not straightforward?

No change for 3.3.

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*