When I first installed Win7, I was having problems with erratic failures to write executable files while running the D test suite. Eventually, I discovered that Windows Defender was the problem, as it tried to do a virus can on every exe the test suite produced.

Turning off WD helped a lot, but I still got those failures every once in a while.

I have since discovered that "Microsoft Security Essentials" was doing a "real time scan", mucking things up. That has to be turned off, too.

Am 10/6/2012 8:41 AM, schrieb Walter Bright:
> When I first installed Win7, I was having problems with erratic failures to write executable files while running the D test suite. Eventually, I discovered that Windows Defender was the problem, as it tried to do a virus can on every exe the test suite produced.
> 
> Turning off WD helped a lot, but I still got those failures every once in a while.
> 
> I have since discovered that "Microsoft Security Essentials" was doing a "real time scan", mucking things up. That has to be turned off, too.

Jep, it's definitely not easy to get this reliable on Windows. Back when I had a similar problem, an explorer window displaying the same folder also caused this.

On Saturday, 6 October 2012 at 07:33:51 UTC, Sönke Ludwig wrote:
> Am 10/6/2012 8:41 AM, schrieb Walter Bright:
>> When I first installed Win7, I was having problems with erratic failures
>> to write executable files while running the D test suite. Eventually, I
>> discovered that Windows Defender was the problem, as it tried to do a
>> virus can on every exe the test suite produced.
>> 
>> Turning off WD helped a lot, but I still got those failures every once
>> in a while.
>> 
>> I have since discovered that "Microsoft Security Essentials" was doing a
>> "real time scan", mucking things up. That has to be turned off, too.
>
> Jep, it's definitely not easy to get this reliable on Windows. Back when
> I had a similar problem, an explorer window displaying the same folder
> also caused this.

This happens, because contrary to UNIX based systems, Windows has real locks.

On one side, it is good as the operating system real enforces them. On the other hand it can lead to such scenarios if the applications are not properly coded to work with file locking mechanisms.

UNIX systems on the other hand, still have the cooperating locks of the old days, meaning if my application doesn't give a damn about locks, it still can manipulate the file. Which might have some nasty consequences.

Does any other operating system makes use of cooperative locks?

--
Paulo

On 10/6/2012 2:25 AM, Paulo Pinto wrote:
> On the other
> hand it can lead to such scenarios if the applications are not properly coded to
> work with file locking mechanisms.

Both Optlink and Windows link fail with this :-)

(The error code Optlink gets from Windows when it tries to create the EXE file is something along the lines of the EXE file is in use by another application.)

On Sat, 06 Oct 2012 13:05:32 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 10/6/2012 2:25 AM, Paulo Pinto wrote:
>> On the other
>> hand it can lead to such scenarios if the applications are not properly coded to
>> work with file locking mechanisms.
>
> Both Optlink and Windows link fail with this :-)
>
> (The error code Optlink gets from Windows when it tries to create the EXE file is something along the lines of the EXE file is in use by another application.)

It's odd that these fail because many/most virus scanners are written using file system filter drivers which operate in the IO stack, blocking CreateFile/open to scan the file, meaning most user processes don't even notice them (except for a very brief pause on CreateFile/open).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/