[erlang-bugs] Bug in file I/O under Windows.

[John Hughes]

Couldn't figure out how to turn McAfee off, but I ran the tests on my other
machine with Norton 360 disabled--same results. I have found a work-around,
however, which consists of simply retrying operations that return
{error,eacces} until they succeed. The one exception is file:delete, which
can return ok *even though it failed*. In this case the work-around is to
keep calling file:delete until it returns {error,enoent}. With these
workarounds, at least delete, read_file, write_file, make_dir and del_dir
seem to work, even under Vista with McAfee running!

I do think it's a bit rummy that file:delete returns ok when it has not
actually deleted the file...

Weird.

John

-----Ursprungligt meddelande-----
Från: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] 
Skickat: den 4 mars 2008 17:27
Till: John Hughes
Kopia: erlang-bugs@REDACTED
Ämne: Re: SV: [erlang-bugs] Bug in file I/O under Windows.

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
> 
> 
>