This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author javen72
Recipients amaury.forgeotdarc, eckhardt, ggenellina, javen72
Date 2009-01-20.09:03:13
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1232442198.77.0.523727743682.issue4944@psf.upfronthosting.co.za>
In-reply-to
Content
I did trace the order of file creation and process launch. It shows the
file is indeed created before the process launch.

I did another investigation. I added a new process, "cmd.exe /c copy
Makefile NewMakefile", to copy the the Makefile created, just before
launching the "nmake.exe" process. The strangest thing happened again:
each makefile was copied successful but there's still "makefile not
found" reported by "nmake.exe" process. I tried standalone copy
application "xcopy.exe" and the result was the same. So I guess that
"cmd.exe", "xcopy.exe" and "nmake.exe" might use different families of
API or different mode (sync vs async) to access file.

I decided to try the code you provided. In checkfile.c, fopen is used to
test the file existence. I changed it to the Windows native API
CreateFile and I also added a file write operation in order to make it
more similar to the real case. Eventually, the problem was reproduced in
your code. Following are the successful number of creating 1000 files 5
times in different file sizes:

Create file in 403 bytes,
  985, 992, 984, 989, 992 (no flush after creation)
  883, 886, 907, 909, 915 (flush after creation)
  
Create file in 4061 bytes
  983, 976, 982, 977, 983 (no flush after creation)
  654, 672, 684, 686, 648 (flush after creation)
  
Create file in 16461 bytes:
  970, 967, 963, 963, 971 (no flush after creation)
  598, 664, 711, 653, 623 (flush after creation)

In summary:
  a. Using fopen to test a file existence in check_file.c will never
report failure, no matter buffer is flushed or not.
  b. Using CreateFile (read mode) to test a file existence in
check_file.c will always report failure. The bigger the file size will
cause more failure reported; the flush operation after file creation in
test_file_flush.py will cause more failure reported; the flush operation
after new file creation in check_file.c will cause more failure
reported; no flush operation in both check_file.c and test_file_flush.py
almost cause no failure.

I don't know what's root cause: GIL, Python thread state switch, Python
file buffer or Windows FileCreate API. I'm just certain there's race
condition between Python and Windows.
History
Date User Action Args
2009-01-20 09:03:19javen72setrecipients: + javen72, amaury.forgeotdarc, ggenellina, eckhardt
2009-01-20 09:03:18javen72setmessageid: <1232442198.77.0.523727743682.issue4944@psf.upfronthosting.co.za>
2009-01-20 09:03:17javen72linkissue4944 messages
2009-01-20 09:03:15javen72create