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
> 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
ACTIVITY SUMMARY (10/30/07 - 11/06/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1323 open (+16) / 11557 closed (+19) / 12880 total (+35)
Open issues with patches: 419
Average durati
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 i
> 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
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
>> 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
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 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
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
> 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"" <[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
Mike, thanks for reviewing the bugs and for creating a patch. Good work!
On Nov 2, 2007 2:23 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Klaas wrote:
> > http://bugs.python.org/issue1705170: reproduced. Conjecture as to
> > why it is occurring, but I don't know the guts well enough to pr
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
16 matches
Mail list logo
