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

[John Hughes]

Here's some code to replicate the bug without QuickCheck:

-module(bug).
-compile(export_all).

bug() ->
    bug(1).

bug(N) ->
    if 
	N rem 1000==0 ->
	    io:format("~p,",[N]);
	true ->
	    ok
    end,
    case catch test() of
	{'EXIT',Reason} ->
	    io:format("After ~p tests: ~p~n",[N,Reason]);
	_ ->
	    bug(N+1)
    end.

test() ->
    ok = file:write_file(bug,<<>>),
    ok = file:delete(bug),
    {error,enoent} = file:delete(bug).

On my Vista machine, it took about three quarters of a million iterations to
provoke a test failure.

John

-----Ursprungligt meddelande-----
Från: John Hughes [mailto:john.hughes@REDACTED] 
Skickat: den 9 mars 2008 18:16
Till: 'Dmitriy Kargapolov'
Kopia: erlang-bugs@REDACTED
Ämne: SV: SV: [erlang-bugs] Bug in file I/O under Windows.

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