Good thing the author wasn't randomly rewriting a file, then, and that the file was deleted and inferably unlikely to be used in a critical operation!
Restarting MySQL is a violent operation. For large databases, it can take several minutes. If I can avoid it, I do so, and this was a really clever workaround for an issue that indeed avoided a restart. That's a good thing.
> Good thing the author wasn't randomly rewriting a file, then, and that the file was deleted and inferably unlikely to be used in a critical operation!
That's not at all true. It's very common unix practice to open a file, delete it, and then use it for critical operations.
I find it quite ironic that you and author of the article completely misunderstand what is happening.
Creating then deleting a temporary file is very common technique to make sure that that for will be removed as soon as the application closes it, it also is used to make sure that nothing will tamper with it. I find amusing that author found a way to still tamper with it.
Now depending on what the file was used for either the corrupted files caused database to return corrupted data to the user, write corrupted data to the database, our in the best scenario return error to the application issuing the query.
open's O_TMPFILE (since Linux 3.11) does exactly that without creating a named file and immediately removing it from the filesystem. I don't argue that the other technique isn't common though.
Restarting MySQL is a violent operation. For large databases, it can take several minutes. If I can avoid it, I do so, and this was a really clever workaround for an issue that indeed avoided a restart. That's a good thing.