Re: Why exception from os.path.exists()?

On 2018-06-13 23:56:09 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : > > POSIX specifies a number of error codes which can be returned by stat(): [...] > > So none of these is a good choice for the errno parameter of an OSError > > to be thrown. > > The natural errno value would be EINVAL,

Re: Why exception from os.path.exists()?

"Peter J. Holzer" : > POSIX specifies a number of error codes which can be returned by stat(): > > [EACCES] > Search permission is denied for a component of the path prefix. > [EIO] > An error occurred while reading from the file system. > [ELOOP] > A loop exists in symbolic links

Re: Why exception from os.path.exists()?

On 2018-06-11 14:23:42 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : > > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: > >> Baking a limitation of some file systems into the high-level > >> interface is simply a *bad idea*. > > > > We aren't talking about a high-level interface here. >

Re: Why exception from os.path.exists()?

On 2018-06-13 10:10:03 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : > > On 2018-06-11 12:24:54 +, Steven D'Aprano wrote: > >> It also clearly states: > >> > >> All functions in this module raise OSError in the case of > >> invalid or inaccessible file names and paths, or other >

Re: Why exception from os.path.exists()?

On Wed, 13 Jun 2018 10:10:03 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : [...] >> I wasn't entirely clear here. What I meant is that POSIX systems, as a >> group, provide no such way. > > I still don't see how POSIX is directly relevant here. Linux users like to sneer at Windows users

Re: Why exception from os.path.exists()?

"Peter J. Holzer" : > On 2018-06-11 12:24:54 +, Steven D'Aprano wrote: >> It also clearly states: >> >> All functions in this module raise OSError in the case of >> invalid or inaccessible file names and paths, or other >> arguments that have the correct type, but are not

Re: Why exception from os.path.exists()?

On 2018-06-11 12:24:54 +, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 12:31:09 +0200, Peter J. Holzer wrote: > > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: > >> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > > > > [Note: I was talking about os.stat here, not

Re: Why exception from os.path.exists()?

On 11-06-18 13:59, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 09:55:06 +0200, Antoon Pardon wrote: > >> On 11-06-18 02:28, Steven D'Aprano wrote: > [...] >>> open(foo) raises an exception if foo doesn't exist; >>> >>> os.path.exists(foo) returns False if foo doesn't exist. >> That is not

Re: Why exception from os.path.exists()?

On Mon, 11 Jun 2018 12:31:09 +0200, Peter J. Holzer wrote: > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: >> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > > [Note: I was talking about os.stat here, not os.path.exists. I agree > that os.path.exists (and the other boolean

Re: Why exception from os.path.exists()?

On Mon, 11 Jun 2018 09:55:06 +0200, Antoon Pardon wrote: > On 11-06-18 02:28, Steven D'Aprano wrote: [...] >> open(foo) raises an exception if foo doesn't exist; >> >> os.path.exists(foo) returns False if foo doesn't exist. > > That is not correct. The path can exist and os.path.exists

Re: Why exception from os.path.exists()?

"Peter J. Holzer" : > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: >> Baking a limitation of some file systems into the high-level >> interface is simply a *bad idea*. > > We aren't talking about a high-level interface here. Call it high-level or not, we *are* talking about an interface

Re: Why exception from os.path.exists()?

On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: > On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: [Note: I was talking about os.stat here, not os.path.exists. I agree that os.path.exists (and the other boolean functions) should simply return false] > > I think this is worth

Re: Why exception from os.path.exists()?

On 11-06-18 10:35, Marko Rauhamaa wrote: > Antoon Pardon : >> On 11-06-18 02:28, Steven D'Aprano wrote: >>> The *whole point* of o.p.exists is to return False, not raise an >>> exception. >> And the price is that it will not always give the correct answer. > Yes, but that's still the point of the

Re: Why exception from os.path.exists()?

Antoon Pardon : > On 11-06-18 02:28, Steven D'Aprano wrote: >> The *whole point* of o.p.exists is to return False, not raise an >> exception. > > And the price is that it will not always give the correct answer. Yes, but that's still the point of the function's existence. Marko --

Re: Why exception from os.path.exists()?

Barry Scott : > I think the rule is, if python can pass the string faithfully to the > OS, then do so, otherwise raise an exception that tells the programmer > that they are doing something that the OS does not allow for. Sure, but few application programmers would think of dealing with the

Re: Why exception from os.path.exists()?

> On 11 Jun 2018, at 01:03, Chris Angelico wrote: > > On Mon, Jun 11, 2018 at 9:52 AM, Steven D'Aprano > wrote: >> On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: >> >>> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >>> I'd like to see what their file

Re: Why exception from os.path.exists()?

> On 11 Jun 2018, at 01:28, Steven D'Aprano > wrote: > > On Sun, 10 Jun 2018 22:09:39 +0100, Barry Scott wrote: > >> Singling out os.path.exists as a special case I do think is reasonable. >> All functions that take paths need to have a consistent response to data > > The *mere existence*

Re: Why exception from os.path.exists()?

On 11-06-18 02:28, Steven D'Aprano wrote: > On Sun, 10 Jun 2018 22:09:39 +0100, Barry Scott wrote: > >> Singling out os.path.exists as a special case I do think is reasonable. >> All functions that take paths need to have a consistent response to data > The *mere existence* of os.path.exists means

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: The evidence suggests that using the Carbon APIs, NUL is just another Unicode character. Whatever API replaces Carbon, it will have to deal with file names created under Carbon, and classic Mac, and so likely will support the same. Thsi raises the interesting quesion

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: Besides, it is certainly not true that there are no OSes that can deal with NULs in file names. Classic Mac OS can, as filenames there are represented as Pascal strings (a length byte followed by an array of arbitrary bytes), not NUL-terminated C strings. There's even

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: Hmmm... you know I might just be able to do that. Write a file to a floppy, then mount it under Linux. That still might not tell you much. The Linux system will need a filesystem driver that understands the Mac HFS file system, which is what your classic Mac system will

Re: Why exception from os.path.exists()?

Chris Angelico wrote: I'd like to find out about that. If it doesn't work, it'll be easily provable that it can't be done. Using the shell: % touch colonic:name % ls colonic:name % touch slashy/name touch: slashy/name: No such file or directory (It's trying to create a file in a directory

NUL in file names verified [was Re: Why exception from os.path.exists()?]

Straight from the horse's mouth, Apple's HFS Plus volumes do indeed support NULs in file names. Quote: Indirect node files exist in a special directory called the metadata directory. This directory exists in the volume's root directory. The name of the metadata directory is four null

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 11:06 AM, Steven D'Aprano wrote: > On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > >> I think this is worth keeping, and "I couldn't pass that file name to >> the OS" is a different error than "the OS told me the file doesn't >> exist", so I think it should be

Re: Why exception from os.path.exists()?

On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > I think this is worth keeping, and "I couldn't pass that file name to > the OS" is a different error than "the OS told me the file doesn't > exist", so I think it should be a different exception. What makes you think that NUL bytes are

Re: Why exception from os.path.exists()?

On 06/07/2018 12:45 AM, Chris Angelico wrote: On Thu, Jun 7, 2018 at 1:55 PM, Steven D'Aprano wrote: On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: And an ASCIIZ string cannot contain a byte value of zero. The parallel is exact. Why should we, as Python programmers, care one whit

Re: Why exception from os.path.exists()?

On Sun, 10 Jun 2018 22:09:39 +0100, Barry Scott wrote: > Singling out os.path.exists as a special case I do think is reasonable. > All functions that take paths need to have a consistent response to data The *mere existence* of os.path.exists means that there is not a consistent response to

Re: Why exception from os.path.exists()?

I accidentally did not send this to the list... > On Jun 10, 2018, at 7:10 PM, Bev in TX wrote: > > >> On Jun 10, 2018, at 3:10 PM, Chris Angelico > > wrote: >>> ... >> >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 9:52 AM, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: > >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what their file names are represented as. > > The Finder could very easily be

Re: Why exception from os.path.exists()?

On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: > Can you try creating "spam:ham" and "spam/ham"? If they're both legal, > I'd like to see what their file names are represented as. The Finder could very easily be substituting another character, like Konqueror (the KDE 3 file manager)

Re: Why exception from os.path.exists()?

On 2018-06-11 00:28:11 +0300, Marko Rauhamaa wrote: > Barry Scott : > > Singling out os.path.exists as a special case I do think is > > reasonable. > > I don't think anyone has proposed that. While I brought up > os.path.exists() in my bug report, os.path.isfile(), os.path.isdir() etc > should

Re: Why exception from os.path.exists()?

Barry Scott : > Singling out os.path.exists as a special case I do think is > reasonable. I don't think anyone has proposed that. While I brought up os.path.exists() in my bug report, os.path.isfile(), os.path.isdir() etc should obviously be addressed simultaneously. It may even be that the fix

Re: Why exception from os.path.exists()?

> On 10 Jun 2018, at 21:10, Chris Angelico wrote: > > On Mon, Jun 11, 2018 at 12:45 AM, Bev in TX wrote: >>> * One with an embedded / in the file name >> >> This is easily done in Finder, where I created a folder named "my/slash”. >> When I list it at the command line in Terminal, this shows

Re: Why exception from os.path.exists()?

On 2018-06-10 09:45:06 -0500, Bev in TX wrote: > On Jun 10, 2018, at 5:49 AM, Peter J. Holzer wrote: > > On 2018-06-07 12:47:15 +, Steven D'Aprano wrote: > >> But it doesn't do that. "Pathnames cannot contain NUL" is a falsehood > >> that programmers wrongly believe about paths. HFS Plus and

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 6:22 AM, Marko Rauhamaa wrote: > Chris Angelico : >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what their file names are represented as. > > I think Bev already explained it. At Unix level, you can't have slashes > in

Re: Why exception from os.path.exists()?

Chris Angelico : > Can you try creating "spam:ham" and "spam/ham"? If they're both legal, > I'd like to see what their file names are represented as. I think Bev already explained it. At Unix level, you can't have slashes in filenames. At GUI level, you can't have colons in filenames. Unix

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 12:45 AM, Bev in TX wrote: >> * One with an embedded / in the file name > > This is easily done in Finder, where I created a folder named "my/slash”. > When I list it at the command line in Terminal, this shows up as "my:slash”, > with the slash shown as a colon. > If I

Re: Why exception from os.path.exists()?

Marko Rauhamaa wrote: > Chris Angelico : > > > Marko Rauhamaa wrote: > >> > >> This surprising exception can even be a security issue: > >> > >>>>> os.path.exists("\0") > >>Traceback (most recent call last): > >> File "", line 1, in > >> File

Re: Why exception from os.path.exists()?

> On Jun 10, 2018, at 5:49 AM, Peter J. Holzer wrote: > > On 2018-06-07 12:47:15 +, Steven D'Aprano wrote: >> But it doesn't do that. "Pathnames cannot contain NUL" is a falsehood >> that programmers wrongly believe about paths. HFS Plus and Apple File >> System support NULs in paths. >

Re: Why exception from os.path.exists()?

On 2018-06-07 12:47:15 +, Steven D'Aprano wrote: > But it doesn't do that. "Pathnames cannot contain NUL" is a falsehood > that programmers wrongly believe about paths. HFS Plus and Apple File > System support NULs in paths. [...] > But in the spirit of compromise, okay, let's ignore the

Re: Why exception from os.path.exists()?

On Sun, Jun 10, 2018 at 7:06 PM, Marko Rauhamaa wrote: > Chris Angelico : >> It's important to pin down the true cause of the problem, and not >> blame something for doing the proper Pythonic thing. > > So could you tell me what the proper Pythonic fix for the example server > in Python's

Re: Why exception from os.path.exists()?

Chris Angelico : > It's important to pin down the true cause of the problem, and not > blame something for doing the proper Pythonic thing. So could you tell me what the proper Pythonic fix for the example server in Python's documentation would be? Here's the code in question:

Re: Why exception from os.path.exists()?

On Sun, Jun 10, 2018 at 5:53 AM, Ed Kellett wrote: > On 2018-06-08 03:42, Chris Angelico wrote: >> Apart from the one odd bug with SimpleHTTPServer not properly sending >> back 500s, I very much doubt that the original concern - namely that >> os.path.exists() and os.stat() raise ValueError if

Re: Why exception from os.path.exists()?

On 2018-06-08 03:42, Chris Angelico wrote: > Apart from the one odd bug with SimpleHTTPServer not properly sending > back 500s, I very much doubt that the original concern - namely that > os.path.exists() and os.stat() raise ValueError if therels a %00 in > the URL - can be abused effectively.

Re: Why exception from os.path.exists()?

On Fri, Jun 8, 2018 at 11:35 AM, Steven D'Aprano wrote: > > (referring to both the NUL bytes in UTF-16 encoded NTFS file names, and > the lack of NUL bytes in common Linux file names). NTFS filenames are stored as wchar_t strings, for which NUL is L"\x00\x00". Individual null bytes are

Re: Why exception from os.path.exists()?

On 08-06-18 13:35, Steven D'Aprano wrote: > On Fri, 08 Jun 2018 09:27:17 +0200, Antoon Pardon wrote: > >> On 08-06-18 04:19, Steven D'Aprano wrote: >>> On Thu, 07 Jun 2018 17:45:06 +1000, Chris Angelico wrote: >>> So... an ASCIIZ string *can* contain that character, or at least a

Re: Why exception from os.path.exists()?

On Fri, 08 Jun 2018 09:27:17 +0200, Antoon Pardon wrote: > On 08-06-18 04:19, Steven D'Aprano wrote: >> On Thu, 07 Jun 2018 17:45:06 +1000, Chris Angelico wrote: >> >>> So... an ASCIIZ string *can* contain that character, or at least a >>> representation of it. Yet it cannot contain "\0". >> You

Re: Why exception from os.path.exists()?

Antoon Pardon : > On 08-06-18 09:45, Marko Rauhamaa wrote: >> Whatever your philosophical tastes, this unexpected feature of >> os.path.exists() (& co) leads to unexpected application behavior IRL, >> and, in the GhostBusters sense, that is bad. > > Sure, I agree that it is unexpected behaviour.

Re: Why exception from os.path.exists()?

On 08-06-18 09:45, Marko Rauhamaa wrote: > Whatever your philosophical tastes, this unexpected feature of > os.path.exists() (& co) leads to unexpected application behavior IRL, > and, in the GhostBusters sense, that is bad. Sure, I agree that it is unexpected behaviour. But does that mean the

Re: Why exception from os.path.exists()?

Antoon Pardon : > On 08-06-18 04:19, Steven D'Aprano wrote: >> On Thu, 07 Jun 2018 17:45:06 +1000, Chris Angelico wrote: >> >>> So... an ASCIIZ string *can* contain that character, or >>> at least a representation of it. Yet it cannot contain "\0". >> [...] >> NTFS file systems use UTF-16 encoded

Re: Why exception from os.path.exists()?

On 08-06-18 04:19, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 17:45:06 +1000, Chris Angelico wrote: > >> So... an ASCIIZ string *can* contain that character, or >> at least a representation of it. Yet it cannot contain "\0". > You keep saying that as if it made one whit of difference to what >

Re: Why exception from os.path.exists()?

On 08-06-18 05:12, Ben Finney wrote: > That is immediately followed by more specific advice that says when to > use bytes: > > Unfortunately, some file names may not be representable as strings > on Unix, so applications that need to support arbitrary file names > on Unix should use

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 22:56:49 -0400, Richard Damon wrote: > or we need an alternate API that lets us pass raw bytes as file names Guido's Time Machine strikes again. All the path related functions, include open(), take arguments as either bytes or strings. -- Steven D'Aprano "Ever since I

Re: Why exception from os.path.exists()?

Richard Damon writes: > This does bring up an interesting point. Since the Unix file system > really has file names that are collection of bytes instead of really > being strings, and the Python API to it want to treat them as strings, > then we have an issue that we are going to be stuck with

Re: Why exception from os.path.exists()?

On 6/7/18 9:17 PM, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 15:38:39 -0400, Dennis Lee Bieber wrote: > >> On Fri, 1 Jun 2018 23:16:32 + (UTC), Steven D'Aprano >> declaimed the following: >> >>> It should either return False, or raise TypeError. Of the two, since >>> 3.14159 cannot

Re: Why exception from os.path.exists()?

On Fri, Jun 8, 2018 at 12:16 PM, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 23:25:54 +1000, Chris Angelico wrote: >> Yes, it's a bug. If someone tries a page size of zero, it'll divide by >> zero and bomb. Great. But how is it a vulnerability? It is a >> properly-handled exception. > > Causing

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 17:45:06 +1000, Chris Angelico wrote: > On Thu, Jun 7, 2018 at 1:55 PM, Steven D'Aprano > wrote: >> On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: >> >>> And an ASCIIZ string cannot contain a byte value of zero. The parallel >>> is exact. >> >> Why should we, as

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 23:25:54 +1000, Chris Angelico wrote: [...] >> Does the Python web server suffer from that vulnerability? I would be >> surprised if it were. But it can be induced to crash (an exception, not >> a seg fault) which is certainly a vulnerability. > > "Certainly"? I'm dubious on

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 15:38:39 -0400, Dennis Lee Bieber wrote: > On Fri, 1 Jun 2018 23:16:32 + (UTC), Steven D'Aprano > declaimed the following: > >>It should either return False, or raise TypeError. Of the two, since >>3.14159 cannot represent a file on any known OS, TypeError would be more

Re: Why exception from os.path.exists()?

On Fri, Jun 8, 2018 at 3:10 AM, MRAB wrote: > On 2018-06-07 08:45, Chris Angelico wrote: >> Under Linux, a file name contains bytes, most commonly representing >> UTF-8 sequences. So... an ASCIIZ string *can* contain that character, >> or at least a representation of it. Yet it cannot contain

Re: Why exception from os.path.exists()?

On 2018-06-07 08:45, Chris Angelico wrote: On Thu, Jun 7, 2018 at 1:55 PM, Steven D'Aprano wrote: On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: And an ASCIIZ string cannot contain a byte value of zero. The parallel is exact. Why should we, as Python programmers, care one whit

Re: Why exception from os.path.exists()?

On 2018-06-07 22:46, Chris Angelico wrote: > On Thu, Jun 7, 2018 at 10:18 PM, Steven D'Aprano > 3. http://localhost:8000/te%00st.html > >>> Actually, I couldn't even get Chrome to make that request, so it > >>> obviously was considered by the browser to be invalid. It doesn't matter

Re: Why exception from os.path.exists()?

On 07-06-18 14:47, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 10:04:53 +0200, Antoon Pardon wrote: > >> On 07-06-18 05:55, Steven D'Aprano wrote: >>> Python strings are rich objects which support the Unicode code point \0 >>> in them. The limitation of the Linux kernel that it relies on NULL-

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 11:09 PM, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 22:46:09 +1000, Chris Angelico wrote: > >>> I wonder how many publicly facing web servers can be induced to either >>> crash, or serve the wrong content, this way? >>> >>> >> Define "serve the wrong content". You could

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 22:46:09 +1000, Chris Angelico wrote: >> I wonder how many publicly facing web servers can be induced to either >> crash, or serve the wrong content, this way? >> >> > Define "serve the wrong content". You could get the exact same content > by asking for "te" instead of

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 10:13 PM, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 19:47:03 +1000, Chris Angelico wrote: > >> To be fair, it's somewhat unideal behaviour - I would prefer to see an >> HTTP 500 come back if the server crashes - but I can't see that that's a >> security problem. > > You

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 10:04:53 +0200, Antoon Pardon wrote: > On 07-06-18 05:55, Steven D'Aprano wrote: >> Python strings are rich objects which support the Unicode code point \0 >> in them. The limitation of the Linux kernel that it relies on NULL- >> terminated byte strings is irrelevant to the

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 10:18 PM, Steven D'Aprano wrote: > On Thu, 07 Jun 2018 13:47:07 +0300, Marko Rauhamaa wrote: > >> Chris Angelico : >> >>> On Thu, Jun 7, 2018 at 7:29 PM, Marko Rauhamaa >>> wrote: 3. http://localhost:8000/te%00st.html => The server crashes with a

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 13:47:07 +0300, Marko Rauhamaa wrote: > Chris Angelico : > >> On Thu, Jun 7, 2018 at 7:29 PM, Marko Rauhamaa >> wrote: >>> 3. http://localhost:8000/te%00st.html >>> >>> => The server crashes with a ValueError and the TCP connection is >>> reset >>> >>> >>

Re: Why exception from os.path.exists()?

On Thu, 07 Jun 2018 19:47:03 +1000, Chris Angelico wrote: > To be fair, it's somewhat unideal behaviour - I would prefer to see an > HTTP 500 come back if the server crashes - but I can't see that that's a > security problem. You think that being able to remotely crash a webserver isn't a

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 8:47 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Thu, Jun 7, 2018 at 7:29 PM, Marko Rauhamaa wrote: >>> 3. http://localhost:8000/te%00st.html >>> >>> => The server crashes with a ValueError and the TCP connection is >>> reset >>> >> it's somewhat

Re: Why exception from os.path.exists()?

Chris Angelico : > On Thu, Jun 7, 2018 at 7:29 PM, Marko Rauhamaa wrote: >> 3. http://localhost:8000/te%00st.html >> >> => The server crashes with a ValueError and the TCP connection is >> reset >> > > Actually, I couldn't even get Chrome to make that request, so it > obviously

Re: Why exception from os.path.exists()?

On 07-06-18 11:29, Marko Rauhamaa wrote: > Antoon Pardon : > >> On 07-06-18 05:55, Steven D'Aprano wrote: >>> As a Python programmer, how does treating NUL specially make our life >>> better? >> By treating possible path values differently from impossible path >> values. > There are all kinds of

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 7:29 PM, Marko Rauhamaa wrote: > This is a security risk. Here is a brief demonstration. Copy the example > HTTP server from: > >https://docs.python.org/3/library/http.server.html?highlight=h >ttp#http.server.SimpleHTTPRequestHandler> > > Run the server. Try these

Re: Why exception from os.path.exists()?

Marko Rauhamaa : > This is a security risk. Here is a brief demonstration. Copy the example > HTTP server from: > >https://docs.python.org/3/library/http.server.html?highlight=h >ttp#http.server.SimpleHTTPRequestHandler> > > [...] > > 3. http://localhost:8000/te%00st.html > > =>

Re: Why exception from os.path.exists()?

Antoon Pardon : > On 07-06-18 05:55, Steven D'Aprano wrote: >> As a Python programmer, how does treating NUL specially make our life >> better? > > By treating possible path values differently from impossible path > values. There are all kinds of impossibility. The os.stat() reports those

Re: Why exception from os.path.exists()?

On 07-06-18 05:55, Steven D'Aprano wrote: > Python strings are rich objects which support the Unicode code point \0 > in them. The limitation of the Linux kernel that it relies on NULL- > terminated byte strings is irrelevant to the question of what > os.path.exists ought to do when given a path

Re: Why exception from os.path.exists()?

On Thu, Jun 7, 2018 at 1:55 PM, Steven D'Aprano wrote: > On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: > >> And an ASCIIZ string cannot contain a byte value of zero. The parallel >> is exact. > > Why should we, as Python programmers, care one whit about ASCIIZ strings? > They're not

Re: Why exception from os.path.exists()?

On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: > And an ASCIIZ string cannot contain a byte value of zero. The parallel > is exact. Why should we, as Python programmers, care one whit about ASCIIZ strings? They're not relevant. You might as well say that file names cannot contain

Re: Why exception from os.path.exists()?

On Tue, 05 Jun 2018 17:28:24 +0200, Peter J. Holzer wrote: [...] > If a disk with a file system which allows embedded NUL characters is > mounted on Linux (let's for the sake of the argument assume it is HFS+, > although I have to admit that I don't know anything about the internals > of that

Re: Why exception from os.path.exists()?

On Tue, Jun 5, 2018 at 3:28 PM, Peter J. Holzer wrote: > > Now, if MacOS uses something like that, this is a different matter. > Presumably (since HFS+ is a native file system) the kernel deals with > NUL characters in a straightforward manner. It might even have a > (non-POSIX) API to expose

Re: Why exception from os.path.exists()?

On 2018-06-05 07:37:34 +, Steven D'Aprano wrote: > On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote: > > On 2018-06-04 13:23:59 +, Steven D'Aprano wrote: > >> I don't know whether or not the Linux OS is capable of accessing > >> files with embedded NULs in the file name. But Mac

Re: Why exception from os.path.exists()?

On Tue, Jun 5, 2018 at 11:11 PM, Steven D'Aprano wrote: > On Tue, 05 Jun 2018 20:15:01 +1000, Chris Angelico wrote: > >> On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano >> wrote: >>> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote: >>> On 2018-06-04 13:23:59 +, Steven D'Aprano

Re: Why exception from os.path.exists()?

On Tue, 05 Jun 2018 20:15:01 +1000, Chris Angelico wrote: > On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano > wrote: >> On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote: >> >>> On 2018-06-04 13:23:59 +, Steven D'Aprano wrote: >> [...] >> I don't know whether or not the Linux OS

Re: Why exception from os.path.exists()?

On Tue, Jun 5, 2018 at 5:37 PM, Steven D'Aprano wrote: > On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote: > >> On 2018-06-04 13:23:59 +, Steven D'Aprano wrote: > [...] > >>> I don't know whether or not the Linux OS is capable of accessing files >>> with embedded NULs in the file

Re: Why exception from os.path.exists()?

On Mon, 04 Jun 2018 22:13:47 +0200, Peter J. Holzer wrote: > On 2018-06-04 13:23:59 +, Steven D'Aprano wrote: [...] >> I don't know whether or not the Linux OS is capable of accessing files >> with embedded NULs in the file name. But Mac OS is capable of doing so, >> so it should be

Re: Why exception from os.path.exists()?

On Sat, Jun 2, 2018 at 11:28 AM, Chris Angelico wrote: > > I also can't find anything about path names there. What does POSIX say > about the concept of relative paths? Does Windows comply with that? Certainly Windows file-system paths are not POSIX compatible. Seven path types are supported: *

Re: Why exception from os.path.exists()?

On 2018-06-04 13:23:59 +, Steven D'Aprano wrote: > On Mon, 04 Jun 2018 13:33:28 +0100, Paul Moore wrote: > > But there's also the question of what capability the kernel API has to > > express the queries. The fact that the Unix API (and the Windows one, in > > most cases - although as Eryk Sun

Re: Why exception from os.path.exists()?

On 2018-06-03, Gregory Ewing wrote: > Steven D'Aprano wrote: >> Do you really mean to say that a computer that won't boot is POSIX >> compliant? > > No, I was pointing out the absurdity of saying that the Windows > kernel layer is POSIX compliant, which is what the post I was > replying to

Re: Why exception from os.path.exists()?

On Mon, 04 Jun 2018 13:33:28 +0100, Paul Moore wrote: > But there's also the question of what capability the kernel API has to > express the queries. The fact that the Unix API (and the Windows one, in > most cases - although as Eryk Sun pointed out there are exceptions in > the Windows kernel

Re: Why exception from os.path.exists()?

On 4 June 2018 at 13:01, Steven D'Aprano wrote: >> Turns out that this is a limitation on Windows as well. The \0 is not >> allowed for Windows, macOS and Posix. > > We -- all of us, including myself -- have been terribly careless all > through this discussion. The fact is, this should not be an

Re: Why exception from os.path.exists()?

Barry Scott : > os.path.exists() is not special and I don't think should be be changed. You are right that os.path.exists() might be logically tied to other os.* facilities. The question is, should the application be cognizant of the seam between the standard library and the operating system

Re: Why exception from os.path.exists()?

On Mon, 04 Jun 2018 11:16:21 +0100, Barry Scott wrote: [...] > Turns out that this is a limitation on Windows as well. The \0 is not > allowed for Windows, macOS and Posix. We -- all of us, including myself -- have been terribly careless all through this discussion. The fact is, this should not

Re: Why exception from os.path.exists()?

> On 1 Jun 2018, at 14:23, Paul Moore wrote: > > On 1 June 2018 at 13:15, Barry Scott wrote: >> I think the reason for the \0 check is that if the string is passed to the >> operating system with the \0 you can get surprising results. >> >> If \0 was not checked for you would be able to get

Re: Why exception from os.path.exists()?

On Sun, 03 Jun 2018 10:38:34 +1000, Chris Angelico wrote: > Let's just rewind this subthread a little bit. YOU said that the > behaviour of os.path.exists on Unix systems should be "return False for > invalid things" on the basis that the Windows invalid paths return > False. Remember? No,

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: Do you really mean to say that a computer that won't boot is POSIX compliant? No, I was pointing out the absurdity of saying that the Windows kernel layer is POSIX compliant, which is what the post I was replying to seemed to be saying. -- Greg --

Re: Why exception from os.path.exists()?

On Sun, Jun 3, 2018 at 10:08 AM, Steven D'Aprano wrote: > Chris, you seem to be labouring under the misapprehension that the claim > is that a stock standard Windows installation complies > with the latest version of the POSIX standard. > > That's not the case. > > The claim (and fact) is that

Re: Why exception from os.path.exists()?

On Sun, 03 Jun 2018 11:47:40 +1200, Gregory Ewing wrote: > Paul Moore wrote: >> Windows (the kernel) has the >> capability to implement fork(), but this isn't exposed via the Win32 >> API. To implement fork() you need to go to the raw kernel layer. Which >> is basically what the Windows Linux

Re: Why exception from os.path.exists()?

On Sat, 02 Jun 2018 21:28:41 +1000, Chris Angelico wrote: > On Sat, Jun 2, 2018 at 9:13 PM, Steven D'Aprano > wrote: >> On Sat, 02 Jun 2018 20:58:43 +1000, Chris Angelico wrote: >> > Windows isn't POSIX compliant. Technically, Windows is POSIX compliant. You have to turn off a

Re: Why exception from os.path.exists()?

On 6/2/18 7:47 PM, Gregory Ewing wrote: > Paul Moore wrote: >> Windows (the kernel) has the >> capability to implement fork(), but this isn't exposed via the Win32 >> API. To implement fork() you need to go to the raw kernel layer. Which >> is basically what the Windows Linux subsystem (bash on

  1   2   >