file-related OSErrors should include filename or FD

[ThomasWaldmann]

Feature or enhancement

Proposal:

  # Python 3.11.2
  File "/usr/lib/python3/dist-packages/borg/locking.py", line 291, in save
    with open(self.path, "w") as f:
OSError: [Errno 95] Operation not supported

This is not very helpful:

• it is unclear what exactly failed (something within open, but what exactly?)
• it is unclear what self.path was at that time. the filename should be included in the OSError instance and in the message generated for the traceback.

@hadess tracked this down to be a problem in gvfs, but it was more work due to missing information. For more information, see there:

borgbackup/borg#8120 (comment)

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[ThomasWaldmann]

BTW, not sure if bug or missing feature. Please re-label if this is a bug.

[picnixz]

OSError has filename and filename2 attributes. Are they set in this specific case? (and if so, are they enough for you?). I also think that those attributes are not that well-known.

If they are set, the 3rdparty library you linked should probably use them in their own error message (in which case it becomes a non-CPython issue). If they are not set, then we should probably set them though I'm not sure if we could create reference cycles if whatever is being stored is not a string.

---

I'm not sure we want to actually show which file failed though (i.e., print it). I think we do print the bad file but it depends on the error code.

[ThomasWaldmann]

I can not easily reproduce on my systems, so I can't say whether the attributes were set or not. But my point was that they should be shown in the error msg.

Also, you can't expect everybody using os.* or standard file object methods to wrap all their calls to print the filename themselves.

[picnixz]

But my point was that they should be shown in the error msg.

If you think so, it was right to ask for a feature. I don't think it's a minor feature so I'd suggest discussing this first on discourse: https://discuss.python.org/c/ideas/6.

Also, you can't expect everybody using os.* or standard file object methods to wrap all their calls to print the filename themselves.

I'd say they shouldn't propagate the exception in the wild unless they document it (and then it's up to the caller to handle it correctly). But this is a personal opinion. I'm more interested in knowing whether:

• there has already been a proposal on Discourse (which you should check before posting there)
• there will be support for this feature.

---

Sorry for closing your issue (I'll leave it open for a few days just so that people here also can participate in the discussion) but since it's a feature request that is non-trivial, I think a discussion with a wider audience is better (the tracker here is usually for minor features or for bugs; when it comes to medium-to-major features that could affect third-party packages, we usually ask people to post on Discourse).

Once you've gathered sufficient support or if a core developer supports your request, we'll re-open the issue (we just don't want to have too many pending and opened issues).

[picnixz]

Let's also ask the opinion of the path expert here cc @barneygale.

As a side note, while I also think it's a nice idea, I think:

• we already do it for some OSError (or am I wrong?)
• should we do it if the path is very long? or has bad characters that could mess up the terminal output?

[cmaloney]

For issues in _io (open(), file.read(), file.close(), ...) the fd could point to any of a number of objects which won't necessarily have a filename. The TextIO and BufferedIO layers have no notion of "this is what is being pointed out". The information could definitely be included from FileIO when possible, but I worry that 1. filenames aren't constant during the lifetime of the fd which lives inside the python I/O stack, and 2. there's a number of cases where filenames are commonly removed from fds (ex. anonymous pipes). In just os Python generally is just passed an arbitrary fd so can't do a lot here.

The fd I think would be useful to include (ex. 0, 1, 2 have common meaning), but not sure caching the filename which can become outdated is more useful or will lead to problems. In pathlib.Path.read_bytes and similar potentially doing a raise ... from could be interesting to add context, but worry about breaking code which expects to catch the OSError / exceptions raised today (ex. that a read would block on a non-blocking fd is communicated via an exception)

[picnixz]

Considering Cody's comment, I'll close this one as not planned. We can't always attach a filename or keep a reference to the file descriptor.