Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL)
Description
Interestingly, the issue is present in MySQL 5.7 and 8.0 as well, but only in those releases.
SET GLOBAL innodb_buffer_pool_filename='';
|
SHUTDOWN;
|
Leads to:
|
11.0.1 b075191ba8598af6aff5549e6e19f6255aef258a (Optimized) |
2023-01-24 15:30:26 0 [Note] InnoDB: FTS optimize thread exiting.
|
2023-01-24 15:30:26 0 [Note] InnoDB: Starting shutdown...
|
2023-01-24 15:30:26 0 [Note] InnoDB: Dumping buffer pool(s) to /test/MD090123-mariadb-11.0.1-linux-x86_64-opt/data
|
2023-01-24 15:30:26 0 [ERROR] InnoDB: Cannot delete '/test/MD090123-mariadb-11.0.1-linux-x86_64-opt/data': Is a directory
|
Bug confirmed present in:
MariaDB: 10.3.38 (dbg), 10.3.38 (opt), 10.4.28 (dbg), 10.4.28 (opt), 10.5.19 (dbg), 10.5.19 (opt), 10.6.12 (dbg), 10.6.12 (opt), 10.7.8 (dbg), 10.7.8 (opt), 10.8.7 (dbg), 10.8.7 (opt), 10.9.5 (dbg), 10.9.5 (opt), 10.10.3 (dbg), 10.10.3 (opt), 10.11.2 (opt), 10.11.2 (dbg), 11.0.1 (dbg), 11.0.1 (opt)
MySQL: 5.7.40 (dbg), 5.7.40 (opt), 8.0.31 (dbg), 8.0.31 (opt)
Bug (or feature/syntax) confirmed not present in:
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt)
Interface change: innodb_buffer_pool_filename is now a read-only variable
Attachments
Activity
I addressed this by making the variable innodb_buffer_pool_filename read-only. An adventurous user might still specify innodb_buffer_pool_filename=ibdata1 or something in the server configuration, but short of removing the parameter (which could break compatibility) I do not think we can do much against that.
Theoretically, we could duplicate some logic that is already part of unlink(), maybe poorly. Think of the following, for example:
Is there anything that really needs to be fixed? Directories cannot be deleted by unlink(), as the error message indicates. If you think that some other error message should be issued, what should it be? What if the file initially existed as a regular file, but someone deleted the file and created a directory by the same name, and then caused InnoDB to attempt to access the file?