>> What they do instead is
>> 1. try to delete the file. If that fails for sharing
>>violation, try 2.
>> 2. move the file to the recycle bin, and set the
>>"delete" disposition flag on the file, this will
>>cause it to be removed from the recycle bin when
>>the last handle is clos
> That is what they do with the latest patches. It is pretty much
> equivent to the POSIX system. That requires Native NT Calls, and is
> not part of win32. It is equivlent to marking the file for deletion
> on close, except the other handles do not need to have shared_delete.
> The moving the fil
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Joe Smith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> Exactly the issue.
>> I see the problem here is cygwin's partial POSIX complience. However,
>> Windows NT had a design goal of allowing a com
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>>> Is this also a restriction on CYGWIN? I don't know
>>> anything about CYGWIN but I could imagine that they allow unlink() to
>>> succeed when there's still a file descriptor referencing it, and that
>>> they will
On 7/31/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Is this also a restriction on CYGWIN? I don't know
> >> anything about CYGWIN but I could imagine that they allow unlink() to
> >> succeed when there's still a file descriptor referencing it, and that
> >> they will delete the file when
>> Is this also a restriction on CYGWIN? I don't know
>> anything about CYGWIN but I could imagine that they allow unlink() to
>> succeed when there's still a file descriptor referencing it, and that
>> they will delete the file when you close it.
>
> Exactly. That is exactly what they do.
Not ex
> Regular Windows typically won't let you remove a file when you still
> have it open.
It depends. If FILE_SHARE_DELETE was passed to CreateFile when opening,
you may DeleteFile it while it is still open. Otherwise, you get an
error from DeleteFile.
> Is this also a restriction on CYGWIN?
Cygwin
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Exactly the issue.
> I see the problem here is cygwin's partial POSIX complience. However,
> Windows NT had a design goal of allowing a complient implementation
> of POSIX to be implmented in a subsystem (along with usere
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/31/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> Hmm... The documentation for Cygwin's unlink() implies that it should
>> function the same as a POSIX unlink() except perhaps if a non-Cygwin
>> process
>> has an
On 7/31/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> Hmm... The documentation for Cygwin's unlink() implies that it should
> function the same as a POSIX unlink() except perhaps if a non-Cygwin process
> has an open handle for it without the correct attributes. I see nothing on
> my system that would
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Guido van Rossum schrieb:
>>> I found that in many cases, this is a virus scanner or the indexing
>>> service interfering. They open the file, and then the test suite cannot
>>> delete it.
>>
>> Oh darn. I remember
> > Cygwin's setlocale function only supports the "C" locale.
> > I am a bit suprised that ASCII is returned rather than the system's
> default
> > encoding.
>
> If I understand the situation correctly, you shouldn't be. The C
> locale is defined to use ASCII.
I think you don't. I'm certain
Joe Smith writes:
> Cygwin's setlocale function only supports the "C" locale.
> I am a bit suprised that ASCII is returned rather than the system's default
> encoding.
If I understand the situation correctly, you shouldn't be. The C
locale is defined to use ASCII.
__
Guido van Rossum schrieb:
>> I found that in many cases, this is a virus scanner or the indexing
>> service interfering. They open the file, and then the test suite cannot
>> delete it.
>
> Oh darn. I remember running into that in a completely different
> context. What's the solution? Turn off the
On 7/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> (For whats its worth, Cygwin's python 2.5 (as installed on my system) fails
> >> 2 of the tests in it's version of test_mailbox.py, both with "IOError:
> >> [Errno 13] Permission denied").
>
> I found that in many cases, this is a virus
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>>> If I patch io.py to default to "utf-8" rather than using the filesystem
>>> encoding (ascii), that fixes a few more things. (test_coding.py and
>>> test_minidom.py)
>>
>> How come the filesystem decoding is set to
>> If I patch io.py to default to "utf-8" rather than using the filesystem
>> encoding (ascii), that fixes a few more things. (test_coding.py and
>> test_minidom.py)
>
> How come the filesystem decoding is set to ASCII?
I guess there are two problems: a) MS_WINDOWS isn't defined, and the
relevant
On 7/29/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> There are still some problems with the 'Python' directory for example. This
> is because of a change in the internals of Cygwin.
> Cygwin does have "managed mounts" which allow for case sensitivity.
> Compiling Python inside a managed mount elimina
On 7/29/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> What I have found is that (on CYGWIN) all of marshal seems to work fine
> except for marshal.load().
> marshal.dump()'s output can be read by 2.5's marshal.load() without problem.
> 3k's marshal.load() will not
> load the data from 3k's marshal.dum
"Joe Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>>> >> I'm wondering if the recusion limit on my build is getting set too
>>> >> low
>>
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> >> I'm wondering if the recusion limit on my build is getting set too low
>> >> somehow.
>> >
>> > Can you find out what it is? sys.getrecursionlimit().
>>
>> Hmm..
On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> >> I'm wondering if the recusion limit on my build is getting set too low
> >> somehow.
> >
> > Can you find out what it is? sys.getrecursionlimit().
>
> Hmm... It is a limit of 1000.
> That is probably large enough, no?
Yes, that's what it is fo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>>
>> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> > On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> >> Building Py3k_strun
On 7/18/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> >> Building Py3k_struni under Cygwin I've noticed a few more tests failing
> >> than
> >> the wiki shows.
> >>
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> Building Py3k_struni under Cygwin I've noticed a few more tests failing
>> than
>> the wiki shows.
>> These are using SVN revision 56413.
>>
>> Some spurious error
On 7/17/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> the wiki shows.
> These are using SVN revision 56413.
>
> Some spurious errors seem to occur if Python/ is not remaned temporally. I
> have not included those. (This is
On 7/18/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 2007/7/17, Joe Smith wrote:
> > Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> > the wiki shows.
> > These are using SVN revision 56413.
> >
> > Some spurious errors seem to occur if Python/ is
Hello,
2007/7/17, Joe Smith wrote:
> Building Py3k_struni under Cygwin I've noticed a few more tests failing than
> the wiki shows.
> These are using SVN revision 56413.
>
> Some spurious errors seem to occur if Python/ is not remaned temporally. I
> have not included those. (This is an oddity of
Building Py3k_struni under Cygwin I've noticed a few more tests failing than
the wiki shows.
These are using SVN revision 56413.
Some spurious errors seem to occur if Python/ is not remaned temporally. I
have not included those. (This is an oddity of the cygwin '.exe'
autohandling combined with
29 matches
Mail list logo
