Random failures of _wfopen

  • Thread starter Thread starter PLS
  • Start date Start date
P

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?
 
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?
Click to expand...
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
 
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.
Click to expand...
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
 
The lazy writer is too slow.

PLS said:
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
Click to expand...
 
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.
 
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.
Click to expand...
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
 
PLS said:
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
Click to expand...

Caching doesn't affect these aspects.
 
Back
Top