> 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 tha
> 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 r
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 willin
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> 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 behaviou
> 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 s
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
chan
>>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, , ,
> , 0L, 0L, 0L, 0L, 'nul
> ', '')]
Ok. I
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 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
>> 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
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 cur
> 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 th
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 i
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,
> 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
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 q
>> 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.
>>
>
> I'm not 100% (it calls it through a function pointer and I'm not sure
> I tracked it down
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.pa
>> 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
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.
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* th
> 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
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
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
> 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
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
26 matches
Mail list logo
