Not necessary, but at least McAfee (per my experience) makes original OS
quite unstable and unpredictable, so I would recommend to make tests
with no antivirus guards running just to exclude one possible reason...
Since your result is not well repeatable, I guess some time-outs or race
conditions could be there. No other guess at this time.
Thanks.
John Hughes wrote:
> Yes I do--Norton 360 under XP and McAfee under Vista. Could that be the
> culprit?
>
> John
>
> -----Ursprungligt meddelande-----
> Från: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED]
> Skickat: den 4 mars 2008 15:50
> Till: John Hughes
> Kopia: erlang-bugs@REDACTED
> Ämne: Re: [erlang-bugs] Bug in file I/O under Windows.
>
> In your Windows environment do you have any antivirus online monitoring s/w?
> Thanks.
>
> John Hughes wrote:
>> This bug manifests as follows:
>>
>>
>>
>> Suppose FileName is the name of an existing file to which we have access.
>>
>>
>>
>> file:delete(FileName)
>> returns ok
>>
>>
>> file:write_file(FileName,Bin) returns
>> {error,eacces}
>>
>>
>>
>> This ought not to happen, because we do have access to the file. The
>> documentation says eacces means “Missing permission for writing the file
>> or searching one of the parent directories”, but neither of these is the
>> case—and indeed, if we repeat the same test, then it will almost always
>> succeed as it should.
>>
>>
>>
>> Unfortunately, this bug is rare and very hard to reproduce, so I can’t
>> include instructions for doing so. I found the problem by running random
>> sequences of file:write_file and file:delete commands, operating on a
>> small set of filenames. I tried to get repeatable tests by running each
>> test in a newly created directory, on a newly spawned Erlang node, and
>> after a timer:sleep—but even so, I found that a sequence which failed
>> once could very well go on to succeed the next 100 times I tried it.
>> However, I have been able to collect about 40 examples of the bug using
>> QuickCheck. All of them take the form above; they range in length from 4
>> commands to over 2,000. There are sometimes operations on other files
>> between the delete and the write_file that fails, but never further
>> operations on FileName itself.
>>
>>
>>
>> I’ve observed this behaviour under R11B and R12B, under both Windows XP
>> and Vista. It doesn’t appear to happen at all under Linux.
>>
>>
>>
>> John Hughes
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-bugs
>
>
>