[MDEV-19128] file_name_parse() handes path MLOG_FILE_XXX in OS-dependend way Created: 2019-04-01  Updated: 2019-04-02  Resolved: 2019-04-02

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.2, 10.3.0, 10.4.0
Fix Version/s: 10.2.24, 10.3.15, 10.4.4

Type: Bug Priority: Major
Reporter: Vladislav Vaintroub Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None


 Description   

file_name_parse() handes path MLOG_FILE_XXX in OS-dependend way, making it impossible e.g to prepare backup from Linux on Windows.

As an example, I have this output trying to prepare backup from MDEV-18309 on Windows

 2019-04-01 14:57:16 0 [ERROR] InnoDB: MLOG_FILE_NAME incorrect:./test/t1.ibd
 
2019-04-01 14:57:16 0 [ERROR] InnoDB: ############### CORRUPT LOG RECORD FOUND ##################
 
2019-04-01 14:57:16 0 [Note] InnoDB: Log record type 55, page 211:0. Log parsing proceeded successfully up to 37116468. Previous log record type 128, is multi 0 Recv offset 0, prev 0
 
2019-04-01 14:57:16 0 [Note] InnoDB: Hex dump starting 0 bytes before and ending 100 bytes after the corrupted record:
 
len 100; hex 3780d300000e2e2f746573742f74312e696264003780dd00000e2e2f746573742f74362e69626400370100001f2e2f6d7973716c2f696e6e6f64625f7461626c655f73746174732e69626400370200001f2e2f6d7973716c2f696e6e6f64625f696e6465; as
 
ibd 7    ./mysql/innodb_table_stats.ibd 7    ./mysql/innodb_inde;
 
2019-04-01 14:57:16 0 [Note] InnoDB: Set innodb_force_recovery to ignore this error.
 
2019-04-01 14:57:16 0 [Warning] InnoDB: Log scan aborted at LSN 37148160
 
2019-04-01 14:57:16 0 [ERROR] InnoDB: Plugin initialization aborted at srv0start.cc[1848] with error Generic error
 
[00] 2019-04-01 14:57:17 mariabackup: innodb_init() returned 11 (Generic error).

quick and dirty fix makes it possible again

diff --git a/storage/innobase/log/log0recv.cc b/storage/innobase/log/log0recv.cc
 
index 70a705cd026..c0b31e7f8c4 100644
 
--- a/storage/innobase/log/log0recv.cc
 
+++ b/storage/innobase/log/log0recv.cc
 
@@ -445,8 +445,8 @@ fil_name_parse(
 
        and end in .ibd. */
 
        bool corrupt = is_predefined_tablespace(space_id)
 
                || len < sizeof "/a.ibd\0"
 
-               || (!first_page_no != !memcmp(ptr + len - 5, DOT_IBD, 5))
 
-               || memchr(ptr, OS_PATH_SEPARATOR, len) == NULL;
 
+               || (!first_page_no != !memcmp(ptr + len - 5, DOT_IBD, 5));
 
+               //|| memchr(ptr, OS_PATH_SEPARATOR, len) == NULL;
 
 
 
        byte*   end_ptr = ptr + len;
 
 
 
@@ -513,8 +513,8 @@ fil_name_parse(
 
 
 
                corrupt = corrupt
 
                        || new_len < sizeof "/a.ibd\0"
 
-                       || memcmp(new_name + new_len - 5, DOT_IBD, 5) != 0
 
-                       || !memchr(new_name, OS_PATH_SEPARATOR, new_len);
 
+                       || memcmp(new_name + new_len - 5, DOT_IBD, 5) != 0;
 
+                       //|| !memchr(new_name, OS_PATH_SEPARATOR, new_len);
 
 
 
                if (corrupt) {
 
                        ib::error() << "MLOG_FILE_RENAME2 new_name incorrect:" << ptr



 Comments   
Comment by Vladislav Vaintroub [ 2019-04-02 ]

I tried with 10.4, I've no idea if it affects other versions

Comment by Marko Mäkelä [ 2019-04-02 ]

I see the same code in MariaDB 10.2.2 already. The check fails to take into account that on Microsoft Windows, backslashes would be written as path separators. On Windows, either forward or backward slashes work fine, but on POSIX, only the forward slash would work.

I believe that we must translate the ‘wrong’ path separator to the native format, because fil_name_process() seems to assume that the name is in the native format.

Generated at Thu Feb 08 08:49:15 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.