Random failures of _wfopen

[PLS]

Environment: Win32 code, Windows XP SP2 current on patches.

I am getting seemingly random failues of the line
FILE *tfh = _wfopen(line, L"w+tSTD, ccs=UTF-16LE");

errno is 13, No permissions, and after the _wfopen GetLastError returns
5, access denied.

The file name in "line" is correct, the working directory is correct,
the line has executed many times before (even with the same filename)
and at the point of failure the named file does not exist.

Oddly, if I breakpoint in the debugger after tfh is tested to be NULL
and set the next statement back to the open, it always works. If I
change the second argument to "w+tSTD, ccs=UTF-16LE" it also always
works.

Does anyone have any thoughts on what the problem is?

 

[PLS]

Environment: Win32 code, Windows XP SP2 current on patches.

I am getting seemingly random failues of the line
FILE *tfh = _wfopen(line, L"w+tSTD, ccs=UTF-16LE");

errno is 13, No permissions, and after the _wfopen GetLastError returns
5, access denied.

The file name in "line" is correct, the working directory is correct,
the line has executed many times before (even with the same filename)
and at the point of failure the named file does not exist.

Oddly, if I breakpoint in the debugger after tfh is tested to be NULL
and set the next statement back to the open, it always works. If I
change the second argument to "w+tSTD, ccs=UTF-16LE" it also always
works.

Does anyone have any thoughts on what the problem is?

Oops, that should be changing the second argument to
"w+tST, ccs=UTF-16LE" makes it always work. In other words, it's the
delete that causes the problem.

++PLS

 

[PLS]

Oops, that should be changing the second argument to
"w+tST, ccs=UTF-16LE" makes it always work. In other words, it's the
delete that causes the problem.

One other thought, because this has the feel of a timing problem about
it. The nature of the program is that it may, as above, open file
"XXXX1.TXT", close it, and almost immediately open the same name again.

Are the deletes caused by the D option or by the
FILE_FLAG_DELETE_ON_CLOSE option on CreateFile done synchronously with
the close? Or can the name somehow hang around for a short period such
that opening a file with the same options and the same name very quickly
will fail?

++PLS

 

[Roberto Baggio]

The lazy writer is too slow.

One other thought, because this has the feel of a timing problem about
it. The nature of the program is that it may, as above, open file
"XXXX1.TXT", close it, and almost immediately open the same name again.

Are the deletes caused by the D option or by the
FILE_FLAG_DELETE_ON_CLOSE option on CreateFile done synchronously with
the close? Or can the name somehow hang around for a short period such
that opening a file with the same options and the same name very quickly
will fail?

++PLS

 

[Alexander Grigoriev]

No. This is an artifact of certain crappy antivirus.

 

[Alexander Grigoriev]

You see an effect of a bad antivirus. It holds a file open for too long. If
it were properly designed, it would access the file only while holding to
the app handle.

 

[PLS]

You see an effect of a bad antivirus. It holds a file open for too long. If
it were properly designed, it would access the file only while holding to
the app handle.

I was guessing that it dependend on the cache process to delete the
file. In any case, changing the code so that file names were not renewed
fixed the problem.

Thanks,
++PLS

 

[Alexander Grigoriev]

I was guessing that it dependend on the cache process to delete the
file. In any case, changing the code so that file names were not renewed
fixed the problem.

Thanks,
++PLS

Caching doesn't affect these aspects.