MySQL Bugs: #78410: Datadir is not portable due to path separators not normalized during recovery

Bug #78410	Datadir is not portable due to path separators not normalized during recovery
Submitted:	11 Sep 2015 14:42	Modified:	2 Oct 2015 11:35
Reporter:	Rahul Sisondia	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.7.9	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
1. Crash server on Windows while heavy DMLs going on
2. Copy datadir on non-windows platform. 
3. Try to start server. 

Observation - InnoDB crash recovery fails with following error message - 

2015-09-11T14:38:37.941969Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 1316941
2015-09-11T14:38:37.942197Z 0 [ERROR] InnoDB: ############### CORRUPT LOG RECORD FOUND ##################
2015-09-11T14:38:37.942227Z 0 [Note] InnoDB: Log record type 55, page 13:0. Log parsing proceeded successfully up to 1319057. Previous log record type 38, is multi 1 Recv offset 2140, prev 2052
2015-09-11T14:38:37.942236Z 0 [Note] InnoDB: Hex dump starting 100 bytes before and ending 100 bytes after the corrupted record:
 len 288; hex 08170300420000000029041703000cf0ffffffff0417030008f0ffffffff04000b0945031f82008117003802180081180000000504020081180028811002008118002a811002008118006881101f9400811800100b001b047465737407757365725f3130260d03000800028000800080068007800480088008800800c1770007000704000020ff7274657374757365725f3130000000000504a400000118011055f2d7d0000000000000000000000000000000010000000000000000370d00001f2e5c6d7973716c5c696e6e6f64625f7461626c655f73746174732e696264001f82008118003802180081190000000505020081190028811002008119002a811002008119006881101f94008119002d0b001c047465737407757365725f3130; asc     B    )                        E       8               (       *       h             test user_10&                        w         rtestuser_10             U                           7    .\mysql\innodb_table_stats.ibd       8               (       *       h        -    test user_10;

This issue happens because tablespace paths are not normalized while reading them from MLOG_FILE_NAME record. Therefore, 
last method call sets the corrupt flag to true. 

	bool corrupt = is_predefined_tablespace(space_id)
		|| first_page_no != 0 // TODO: multi-file user tablespaces
		|| len < sizeof "/a.ibd\0"
		|| memcmp(ptr + len - 5, DOT_IBD, 5) != 0
		|| memchr(ptr, OS_PATH_SEPARATOR, len) == NULL;

How to repeat:
See above

Suggested fix:
Call os_normalize_path(ptr); after reading the file name from redo log in fil_name_parse() method

Posted by developer:
 
Fixed as of the upcoming 5.7.10, 5.8.0 release, and here's the changelog entry:

On Windows, the server exited during crash recovery when started on a
data directory copied form a non-Windows platform. The failure was due to
a file path separator conversion issue. 

Thank you for the bug report.

The changelog entry was revised as follows:

After a crash on Windows, copying the data directory to a non-Windows
platform to perform the restore caused a crash recovery failure on
startup. The code did not convert file path separators from \ to / in the
redo log.