MySQL Bugs: #43775: Handle "Atomic Rename" operations differently on windows?

Bug #43775	Handle "Atomic Rename" operations differently on windows?
Submitted:	20 Mar 2009 23:28	Modified:	23 Mar 2009 8:20
Reporter:	Trent Lloyd	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Windows	Severity:	S3 (Non-critical)
Version:	5.0.68-enterprise-nt-log	OS:	Windows (2003 R2 SP2)
Assigned to:		CPU Architecture:	Any

Description:
I was reading this bug
http://bugs.mysql.com/bug.php?id=39750

And I learned (unknown to me previously, but apparently better known)

One of the bigger problems caused by MySQL on windows is by virus scanners .. seems most common issue is because once you "delete" file, it does not delete until all handles are closed.

This caused for example, temp-pool to cause problems because same filename was re-used rapidly, especially on busy server.

It also occurs to me this is why we see customers (such as the one attached to this issue) hit problems with OPTIMIZE TABLE/ALTER TABLE => as .TMD file is reamed to .MYD but fails because .MYD was first deleted,but still existed when the rename was attempting.

How to repeat:
Sometimes when using "OPTIMIZE TABLE", .MYD fails to delete and .TMD is left behind when using virus scanner.

Suggested fix:
Perhaps a good solution is to do "random file" rename before deleting them.

 * DELETE TABLE *
 - rename table.MYD   table-1237589927.MYD
 - reame TABLE.TMD table.MYD
 - delete table-1237589927.MYD

However I have very little understanding of this whole process, mostly just a thought.  Interested in opinion of more informed developers.

Verifying as D3

"Random file rename" was actually the first patch proposal I done for Bug#39750
http://lists.mysql.com/commits/59327

too bad it got rejected at that time. Maybe now it is the time :)

Any updates on this?