The management of control_file_fd in storage/maria/ma_control_file.c appears sound.

There appears to be a case in my_win_sopen where if my_open_osfhandle exceeds my_file_limit a file will be closed but still returned as opened by:

diff --git a/mysys/my_winfile.c b/mysys/my_winfile.c

index 0c76eb25560..350b4d142e4 100644

--- a/mysys/my_winfile.c

+++ b/mysys/my_winfile.c

@@ -263,6 +263,7 @@ File my_win_sopen(const char *path, int oflag, int shflag, int pmode)

     oflag & (_O_APPEND | _O_RDONLY | _O_TEXT))) == -1)

   {

     CloseHandle(osfh);

+    DBUG_RETURN(-1);

   }

   DBUG_RETURN(fh);                   /* return handle */

This would prevent the return of a closed file handle. The one server use of ma_control_file_open in ha_maria_init might cope with this correctly.

danblack, nope, not really. That code is fine.

The code you're quoting goes like this. Note the fh and osfh variables, those mean 2 different things.

  if ((fh= my_open_osfhandle(osfh, 

    oflag & (_O_APPEND | _O_RDONLY | _O_TEXT))) == -1)

  {

    CloseHandle(osfh);

  }

  DBUG_RETURN(fh);                   /* return handle */

There is no need to insert DBUG_RETURN(-1) after CloseHandle in case of error, it will be done anyway, after the "if" block

slightly simplified, the current logic is this

fh = my_open_osfhandle(osfh...);

if(fh == -1)

  CloseHandle(osfh);

return fh;

There is no need to change it.

Quite right thanks. I'm at a bit of a loss to the the cause of a double close now.

Hello, I'm the guy who reported the bug on StackOverflow. Since this is a major issue I would very much appreciate to learn about a potential workaround or what the actual issue now is so that I can diagnose it properly and peacefully continue working on my project. How exactly is something like this even happening on such an old and reliable DB engine? It's really odd to me. My usage of MySQL is quite straight-forward and nothing out of the ordinary. It may sound ignorant but using more modern C++ may be clever for modernizing and improving file system related code using e.g. the excellent C+17 filesystem instead of this messy low-level C stuff where issues are more opaque than e.g. when a C+ exception is thrown. Either way, thanks for the effort and I hope to hear back soon.

From SO:

For reference, about how many tables are in your SQL file. Are these Aria, InnoDB or a mix?

A procmon recording that is limited to the actions on aria_log_control might be useful (or at least excluding the large writes of a database import).

@Daniel: What about me sending you the database schema and database dump so that you can load both yourself and see about this bug? I'm willing to send you the files privately since they are not too confidential. Is your e-mail address on Jira fine?

Sure.