> 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
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 ha
27 matches
Mail list logo
