Description:
I found a problem in the archive test case on Windows.
In the archive test case, the OPTIMIZE TABLE t2; statement does not work (even though the test case still succeeds due to missing error checks). It fails to replace the old t2.ARZ file with the new optimized file, leaving a dangling t2.ARN file in the var/master-data/test/ directory. And the table is not optimized. I think there are also other cases in archive where the renaming fails, for example I've seen the test case fail with a rename error when run with a Debug build.
I traced through the code with the debugger. On Windows, the my_rename() first deletes the target path, then renames source to target (can't overwrite files with rename() on Windows).
During the test case, when ha_archive::optimize() calls my_rename(), first the unlink() fails and subsequently the rename() fails ('file exists'). However there is missing an error check in ha_archive::optimize(), so the code proceeds, using the old t2.ARZ file (and leaving the .ARN file dangling).
At this point in the test, there are two open handles to test/t2.ARZ. This might be the real cause of the problem, not sure... I think these two open handles (or one of them) causes the unlink() to fail.
How to repeat:
Run the archive test on a Windows build:
mysql-test-run.pl archive
After it ends, check var/master-data/test/, it has left-over files t2.ARN and t5.ARN.
Set a breakpoint in my_rename(), trace the call from ha_archive::optimize, and see that the rename() call fails.
Suggested fix:
Not sure what happens here, but there is some problem with the Windows file semantics on overwriting files that are already open.
Two possibilities are:
1. Make sure that no open handles exists on the .ARZ file during ha_handler::optimize() and other rename operations.
2. Fix the file create/open flags to allow delete and rename despite there being open handles.
So perhaps either there is missing some close() calls, or perhaps the Windows file sharing options to various system calls needs to be fixed?
Description: I found a problem in the archive test case on Windows. In the archive test case, the OPTIMIZE TABLE t2; statement does not work (even though the test case still succeeds due to missing error checks). It fails to replace the old t2.ARZ file with the new optimized file, leaving a dangling t2.ARN file in the var/master-data/test/ directory. And the table is not optimized. I think there are also other cases in archive where the renaming fails, for example I've seen the test case fail with a rename error when run with a Debug build. I traced through the code with the debugger. On Windows, the my_rename() first deletes the target path, then renames source to target (can't overwrite files with rename() on Windows). During the test case, when ha_archive::optimize() calls my_rename(), first the unlink() fails and subsequently the rename() fails ('file exists'). However there is missing an error check in ha_archive::optimize(), so the code proceeds, using the old t2.ARZ file (and leaving the .ARN file dangling). At this point in the test, there are two open handles to test/t2.ARZ. This might be the real cause of the problem, not sure... I think these two open handles (or one of them) causes the unlink() to fail. How to repeat: Run the archive test on a Windows build: mysql-test-run.pl archive After it ends, check var/master-data/test/, it has left-over files t2.ARN and t5.ARN. Set a breakpoint in my_rename(), trace the call from ha_archive::optimize, and see that the rename() call fails. Suggested fix: Not sure what happens here, but there is some problem with the Windows file semantics on overwriting files that are already open. Two possibilities are: 1. Make sure that no open handles exists on the .ARZ file during ha_handler::optimize() and other rename operations. 2. Fix the file create/open flags to allow delete and rename despite there being open handles. So perhaps either there is missing some close() calls, or perhaps the Windows file sharing options to various system calls needs to be fixed?