classification
Title: posix_access swallows all errors
Type: enhancement Stage: needs patch
Components: Library (Lib) Versions: Python 3.3
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, loewis, pitrou, rosslagerwall
Priority: normal Keywords:

Created on 2010-12-22 12:45 by georg.brandl, last changed 2010-12-22 20:16 by loewis.

Messages (3)
msg124500 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-12-22 12:45
access(2) can return errnos that correspond to input errors or general system faults, such as EINVAL, EIO or ENOMEM.  In this case, an exception should be raised instead of returning False.

It is probably best to whitelist those errnos that indicate missing access -- it needs to be discussed whether that is just EACCES, or also e.g. ENOENT.
msg124517 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-12-22 19:57
The list of errnos indicating missing access seems open-ended.
Things such as:

[ENAMETOOLONG]
    The length of a component of a pathname is longer than {NAME_MAX}.
[ENOENT]
    A component of path does not name an existing file or path is an empty string.
[ENOTDIR]
    A component of the path prefix is not a directory, or the path argument contains at least one non- <slash> character and ends with one or more trailing <slash> characters and the last pathname component names an existing file that is neither a directory nor a symbolic link to a directory.
[EROFS]
    Write access is requested for a file on a read-only file system.

... may be considered missing access.
msg124520 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-22 20:16
I don't think we can change this for the maintenance branches. The code behaves according to the documentation:

    access(path, mode) -> True if granted, False otherwise

"False otherwise" is really meant that way: otherwise. The specific condition is indeed not communicated. However, applications are entitled to not seeing exceptions come out of this function.

I would be in favor of changing this in the long term, but then raise exceptions in all cases. Alternatively, have it produce falsish values that encapsulate the error code.
History
Date User Action Args
2010-12-22 20:16:54loewissetnosy: + loewis
messages: + msg124520
2010-12-22 19:57:37pitrousetversions: + Python 3.3, - Python 3.1, Python 2.7, Python 3.2
nosy: + pitrou

messages: + msg124517

type: behavior -> enhancement
2010-12-22 15:48:13rosslagerwallsetnosy: + rosslagerwall
2010-12-22 12:45:08georg.brandlcreate