[issue33721] os.path.exists() ought to return False if pathname contains NUL

Serhiy Storchaka added the comment: os.path.exists() and similar functions will return now False for invalid paths (non-encodable paths on Unix, non-decodable bytes paths on Windows, and paths containing null characters or bytes). -- resolution: -> fixed stage: patch review ->

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Serhiy Storchaka added the comment: New changeset 0185f34ddcf07b78feb6ac666fbfd4615d26b028 by Serhiy Storchaka in branch 'master': bpo-33721: Make some os.path functions and pathlib.Path methods be tolerant to invalid paths. (#7695)

[issue33721] os.path.exists() ought to return False if pathname contains NUL

pacujo added the comment: Eryk Sun: > I only meant that, as an honest error, it has to be ValueError. I didn't > think about raising a fake OSError. > > Note that I didn't say the ValueError shouldn't be ignored by > os.path.exists (et al). In the spirit of the current function, it > probably

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Eryk Sun added the comment: >> It has to be a ValueError since the error is an invalid >> parameter at the Python level. > > How does the first follow from the second? I only meant that, as an honest error, it has to be ValueError. I didn't think about raising a fake OSError. Note that I

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Serhiy Storchaka added the comment: This change looks desirable to me. But it looks too large for backporting it to maintained versions. -- type: behavior -> enhancement versions: +Python 3.8 -Python 3.6 ___ Python tracker

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +7310 stage: -> patch review ___ Python tracker ___ ___

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Steven D'Aprano added the comment: Eryk Sun says: > It has to be a ValueError since the error is an invalid parameter at the > Python level. How does the first follow from the second? Strings with NULs in them aren't errors or invalid parameters at the Python level, and they are legal file

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Steven D'Aprano added the comment: Eric wrote: > I don't know of any OS that supports NULs in filenames HFS, HFS Plus, and Apple File System all support NULs in filenames. HFS Plus volumes include a special special directory called the metadata directory, in the volume's root directory,

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Serhiy Storchaka added the comment: In earlier versions NULs in paths caused silent truncating the path, and this is considered a vulnerability. In 2.7 and earlier versions of 3.x a TypeError was raised in os.path.exists(). ValueError in this function (and many others) is raised since 3.5,

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Eryk Sun added the comment: It has to be a ValueError since the error is an invalid parameter at the Python level. Similarly, in 3.6+ when using bytes paths in Windows, for which Python uses UTF-8 as the file-system encoding, os.path.exists() may raise UnicodeDecodeError: >>> try:

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Eric V. Smith added the comment: I don't know of any OS that supports NULs in filenames (not that my knowledge is encyclopedic). My reason for suggesting we document it is that os.path.exists() returns False for otherwise invalid filenames, where something like open() raises. On Windows:

[issue33721] os.path.exists() ought to return False if pathname contains NUL

R. David Murray added the comment: I seem to recall that this ValueError behavior was discussed at some length and it is the desired behavior. (At some previous point I think everything after the NUL was ignored.) I'm not really sure why it needs to be documented either, NULs are invalid

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Eric V. Smith added the comment: To be clear: os.path.exists('a\x00b') raises ValueError on both Windows and Linux. I think we should just document this behavior and not change it. -- nosy: +eric.smith ___ Python tracker

[issue33721] os.path.exists() ought to return False if pathname contains NUL

Matthew Barnett added the comment: It also raises a ValueError on Windows. For other invalid paths on Windows it returns False. -- nosy: +mrabarnett ___ Python tracker ___

[issue33721] os.path.exists() ought to return False if pathname contains NUL

New submission from pacujo : os.path.exists() returns True or False for all imaginable string arguments except for one that contains NUL ("\0") (Linux). This behavior is not documented in the library. Moreover, it can easily lead to accidents if an externally supplied pathname were to