Sorry, I meant to imply that we would guard FindFirstFile in the same
manner that _stati64 and friends do already (using strpbrk/wcspbrk to
search for ?* in the path). At that point, you have essentially
duplicated the CRT code with the added improvement of using
GetFileAttributes* to
Perhaps a note should be added to the docs that the 'existence' of 'nul',
etc, is inconsistent in Windows and hence, at present, in Python.
That is a statement that I want to get better confirmation on also.
What is the precise condition where Windows (or perhaps just Python?)
would claim that
2007/11/3, Martin v. Löwis [EMAIL PROTECTED]:
GetFileAttributes() doesn't return those, just the FAT filesystem
attributes. GetFileSize and GetFileTime fail.
Ok, so how does msvcrt stat() manage to fill these fields if those
functions fail?
Beyond the question to this specific question, I
As Mask Hammond said, I think that we should rely on what windows is
saying to us as strict as possible. If windows change its behaviour,
ok, I do not think that we need to patch these behaviour holes.
What do you think? Is a mistake to adhere to windows behaviour?
We certainly should rely
2007/11/6, Martin v. Löwis [EMAIL PROTECTED]:
We certainly should rely on the Windows behavior. The next question then
is: What exactly *is* the Windows behavior. Windows is not just
inconsistent across versions, but apparently so even within a single
version.
+1 for QOTW
IIUC,
Martin v. Löwis schreef:
That doesn't really answer the question, though - you merely state
that Python 2.4 calls the CRT, but then my question is still what
kernel32 functions are called to have stat on NUL succeed.
Sure - but what does stat then do when passed NUL?
AFAIK then it doesn't
If yes, we have three paths to follow... leave 2.5 as is and say that
the behaviour change is ok (windows fault), change 2.5 to use the same
API than 2.4 and get the same behaviour, or hardwire the behaviour for
this set of special files...
As you said before, we should avoid hardwiring
2007/11/6, Martin v. Löwis [EMAIL PROTECTED]:
Unfortunately, it seems that none of us is both capable and has
sufficient time to research what the 2.4 behavior actually is;
I'd like to emphasize that I think no changes should be made until
the behavior is fully understood, which it currently
Sure - but what does stat then do when passed NUL?
AFAIK then it doesn't fill in the size and time fields of the structure
(or sets them to a useless/invalid value).
(See http://msdn2.microsoft.com/en-us/library/14h5k7ff(vs.71).aspx)
What specifically on that page tells me how the fields
On 06/11/2007, Martin v. Löwis [EMAIL PROTECTED] wrote:
See above: if stat() (_stat() actually) is called on NUL (or another
device), I don't think it does anything useful with these fields.
You mean, it does nothing documented... AFAICT from the code, it always
fills in something.
From my
From my reading of the CRT source code, _stat() uses FindFirstFile().
This in turn appears to return a valid result on nul -
win32api.FindFile, which is a thin wrapper round FindFirstFile etc,
returns
win32api.FindFiles(nul)
[(32, PyTime:01/01/1601 00:00:00, PyTime:01/01/1601 00:00:00,
Martin v. Löwis schreef:
Sure - but what does stat then do when passed NUL?
AFAIK then it doesn't fill in the size and time fields of the structure
(or sets them to a useless/invalid value).
(See http://msdn2.microsoft.com/en-us/library/14h5k7ff(vs.71).aspx)
What specifically on that page
Martin v. Löwis wrote:
So, the question is what we should do?:
Before this question can be answered, I think we need to fully
understand what precisely is happening in 2.4, and what precisely
is happening in 2.5.
Seeing this thread drag on was enough to get me to find out what
changed.
In order to keep the higher accuracy timestamps for normal files and to
maintain the old behavior, my recommendation would be that the existing
implementation of win32_stat/win32_wstat be extended to use
FindFileFirst if GetFileAttributes* fails. I would be willing to do the
legwork for such
Martin v. Löwis wrote:
In order to keep the higher accuracy timestamps for normal files and to
maintain the old behavior, my recommendation would be that the existing
implementation of win32_stat/win32_wstat be extended to use
FindFileFirst if GetFileAttributes* fails. I would be willing to do
On Oct 30, 2007 4:10 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
My question now is what specific kernel32 functions Python 2.4
calls to determine that NUL is a file; before that question
is sufficiently answered, I don't think any action should be
taken.
os.path.exist() in win32
On Oct 24, 2007 11:05 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
So, the question is what we should do?:
Before this question can be answered, I think we need to fully
understand what precisely is happening in 2.4, and what precisely
is happening in 2.5.
AFAICT, it is *not* the case that
Chris Mellon schrieb:
On Oct 24, 2007 11:05 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
So, the question is what we should do?:
Before this question can be answered, I think we need to fully
understand what precisely is happening in 2.4, and what precisely
is happening in 2.5.
AFAICT, it
My question now is what specific kernel32 functions Python 2.4
calls to determine that NUL is a file; before that question
is sufficiently answered, I don't think any action should be
taken.
os.path.exist() in win32 just calls os.stat() and decides it doesn't
exist if an error is
Hi, people!
I'm following the issue 1311: http://bugs.python.org/issue1311
There (and always talking in windows), the OP says the in Py2.4
os.path.exists(nul) returned True and now in 2.5 returns False. Note
that nul is an special file, something like /dev/null.
We made some tests, and we have
On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote:
There (and always talking in windows), the OP says the in Py2.4
os.path.exists(nul) returned True and now in 2.5 returns False. Note
that nul is an special file, something like /dev/null.
It's special, but in a different way. /dev/null
So, the question is what we should do?:
1. Rely on the kernel32 function and behaves like it says?
2. Return a fixed response for this special file nul?
Personally, I prefer the first one, but it changed the semantic of
os.path.exists(nul) (but this semantic is not clear, as we get
Fred Drake wrote:
On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote:
There (and always talking in windows), the OP says the in Py2.4
os.path.exists(nul) returned True and now in 2.5 returns False. Note
that nul is an special file, something like /dev/null.
It's special, but in a different
Fred Drake wrote:
It's special, but in a different way. /dev/null really exists in the
Unix filesystem; nul is more magical than that.
What's more, it has peers: prn, com1 and others like that.
For the record, the fixed names 'aux', 'con', 'nul', and 'prn' along
with the set of
So, the question is what we should do?:
Before this question can be answered, I think we need to fully
understand what precisely is happening in 2.4, and what precisely
is happening in 2.5.
AFAICT, it is *not* the case that Python 2.4 (indirectly) has
hard-coded the names CON, PRN, NUL etc. in
25 matches
Mail list logo
