[MDEV-16456] InnoDB error "returned OS error 71" complains about wrong path Created: 2018-06-10  Updated: 2018-06-12  Resolved: 2018-06-12

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.0, 10.1, 10.2, 10.3
Fix Version/s: 10.0.36, 10.1.34, 10.2.16, 10.3.8

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: upstream


 Description   

This simple 2-liner makes InnoDB produce the notorious "returned OS error 71" in the command line.

--source include/have_innodb.inc
 
CREATE TABLE t1 (a INT) ENGINE=InnoDB;
 
--error ER_ERROR_ON_RENAME
 
RENAME TABLE t1 TO non_existing_db.t1;
 
 
 
# Cleanup
 
DROP TABLE t1;

The SQL error is of course expected, and the appearance of the accompanying InnoDB error might be considerated legitimate; the problem is what it says:

10.0 c4499a0391

 
2018-06-11 01:06:49 7fb9f297a700  InnoDB: Operating system error number 2 in a file operation.
 
InnoDB: The error means the system cannot find the path specified.
 
180611  1:06:49 [ERROR] InnoDB: File ./test/t1.ibd: 'rename' returned OS error 71.

In the error message, it mentions the valid existing path ./test/t1.ibd, but doesn't mention the problematic non-existing path, and it reads like ./test/t1.ibd does not exist. It's very confusing when it comes to investigation, especially when it's a problem on the user side, when we don't have all the information, don't know which statement was issued and what caused the error.



 Comments   
Comment by Marko Mäkelä [ 2018-06-11 ]

The problem is that InnoDB is only reporting one file name with the error message:

	ret = rename(oldpath, newpath);
 
 
 
	if (ret != 0) {
 
		os_file_handle_error_no_exit(oldpath, "rename", FALSE);
 
 
 
		return(FALSE);
 
	}

Fixing this requires rewriting all the error reporting code, or maybe as a lesser evil, duplicating the logic of os_file_handle_error_no_exit() for rename, reporting both file names.

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