Bug #70269 Restore of backup doesn't work
Submitted: 8 Sep 2013 12:03 Modified: 18 Mar 2014 18:39
Reporter: nikos dimitrakas Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Workbench Severity:S3 (Non-critical)
Version:6.0.7 OS:Windows
Assigned to: CPU Architecture:Any
Tags: import, restore, workbench

[8 Sep 2013 12:03] nikos dimitrakas
Description:
After using Workbench to create a backup with "Data Export" and "Export to Selfcontained file" the created file cannot be imported/restored (using Data Import/Restore). After selecting the file and pressing "Start Import" the log shows the command and then nothing happens for a long time until I eventuelly have to press "Stop". 

After some experiments I have concluded that it seems to depend on the extra \ added to the import command Workbench tries to run.

This is how the commands looks:
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe" --defaults-extra-file="c:\docume~1\nikos\locals~1\temp\tmpe9bzi7.cnf"  --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=test < "C:\\Documents and Settings\\nikos\\Desktop\\test"

This is how it should look:
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe" --defaults-extra-file="c:\docume~1\nikos\locals~1\temp\tmpe9bzi7.cnf"  --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=test < "C:\Documents and Settings\nikos\Desktop\test"

Observe also the inconsistency in the three paths, where two of them use the short file/folder names, while the third is not.

How to repeat:
Just create a database and a table.
Export it as a self-contained file using Data export in Workbench.
Try to import it using Data Import/Restore from Workbench.

Obviously this may work on non Windows platforms, so use Windows.

I have been using MySQL 5.6.13 and WorkBench 6.0.7, but this has been an issue in many previous versions, so it should be possible to repeat this on any version.

Suggested fix:
Use the short folder/file syntax without the double \ in the path to the imported file when generating the command.
[8 Sep 2013 16:56] nikos dimitrakas
The problem seems to exist only when the "Path to mysql Tool" is explicitly set in Workbench Preferences > Administrator. When using the bundled version (by not specifying anything), it works. Maybe the problem is related to how the explicitly specified path is used to run the command. When leaving the field "Path to mysql Tools" empty, the mysql.exe in the Workbench folder is used and then it works. If the path to the exact same mysql.exe file is specified in the field "Path to mysql Tool", then the Import/Restore will get stuck without any error message.
[9 Sep 2013 17:30] MySQL Verification Team
Please print here the path which don't works?. Thanks.
[9 Sep 2013 18:36] nikos dimitrakas
I have tried both of the following and both cause the same problem.

C:\Program Files\MySQL\MySQL Workbench 6.0 CE\mysql.exe
C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe

Both are actually the exact same version.
[10 Sep 2013 10:54] MySQL Verification Team
Thank you for the feedback. If you try the path like (without mysql.exe) ?

C:\Program Files\MySQL\MySQL Workbench 6.0 CE\
or
C:\Program Files\MySQL\MySQL Server 5.6\bin\

Thanks.
[10 Sep 2013 13:51] nikos dimitrakas
That is not allowed. The pop-up window to select the path expects me to select an exe file before I can press OK.
[11 Sep 2013 13:03] MySQL Verification Team
Thank you for the feedback. The below paths don't works for me too:

C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqldump.exe
C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe

Then when back to bundled version works.
[18 Feb 2014 3:05] Andrew Jonkers
I can confirm this is a problem.

Quick fix: REMOVE path from edit->preferences->administrator mysqldump path and mysql path (Even if they currently point to correct location!!!!) i.e. leave the path completely blank and it should now work. (Mine does ;-)

It seems when installing on 64bit OS the installer populates these preference fields, and it does not when installing on 32 bit, so it works on 32 bit OS by default.
[18 Feb 2014 3:30] Andrew Jonkers
To make the path blank, do not use popup window, just manually delete whats in the textbox(es) ;-)
[18 Mar 2014 18:39] Alfredo Kojima
This is actually a duplicate of Bug #54370
[18 Mar 2014 20:15] Juan Rene Ramirez Monarrez
After some testing we managed to reproduce the behavior where the WB is like 
frozed not doing anything, but we found that it is actually working on the 
import. 

The change to be done here is to improve the UI feedback about WB doing some work, 
which is why it was marked as duplicate of Bug #54370. 

Thanks!
[18 Mar 2014 21:13] Andrew Jonkers
I dispute is is a "duplicate of Bug #54370. " 

The reason I say this is that unlike 54370,with this bug, the import NEVER completes, and the schema never shows up in the tables.
[15 Jun 2015 10:28] Micha Wiedenmann
I think I found the problem, please consider "wb_admin_export.py" (method: process_db()):

--- C:\Program Files (x86)\MySQL\MySQL Workbench CE 6.1.7\modules\wb_admin_export.py	2015-06-15 11:57:34.000000000 +0200
+++ C:\Program Files (x86)\MySQL\MySQL Workbench CE 6.1.7\modules\wb_admin_export.py.orig	2014-11-12 01:40:24.000000000 +0200
@@ -160,13 +160,13 @@
                     if self.is_import:
                         fse = sys.getfilesystemencoding()
                         cmd = logstr.encode(fse) if isinstance(arg,unicode) else logstr
                     else:
                         cmd = logstr.encode("utf8") if isinstance(arg,unicode) else logstr
                     log_debug("Executing command: %s\n" % logstr)
-                    p1 = subprocess.Popen(cmd,stdout=respipe or subprocess.PIPE,stdin=subprocess.PIPE, stderr=subprocess.PIPE,startupinfo=info,shell=True)
+                    p1 = subprocess.Popen(cmd,stdout=respipe or subprocess.PIPE,stdin=subprocess.PIPE, stderr=subprocess.PIPE,startupinfo=info,shell=logstr[0] != '"')
                 except OSError, exc:
                     log_error("Error executing command %s\n%s\n" % (logstr, exc))
                     import traceback
                     traceback.print_exc()
                     self.print_log_message("Error executing task: %s" % str(exc))
                     p1 = None

If I change "shell=..." to "shell=True" my import no longer blocks and runs through.

Observations:
 - Import runs if "Preferences->Administration->Path to mysql Tool" is empty.
 - Import does not run with "C:\Program Files (x86)\MySQL\MySQL Workbench CE 6.1.7\mysql.exe".

Possible cause:
db_update() compares the first character of the final command to '"', if the tools setting is empty, the final command will start with "mysql --params ...". If tools is set to a path with whitespace the path will be quoted during the call to

| line 1227, method: start()
|
|        cmd = subprocess.list2cmdline([cmd] + params)

More details:
It seems to me that when the import is started with "Shell=False" reading from stderr blocks:

| line 202, method process_db()
|
|        err = p1.stderr.read()

I have created and appended a test case.

Regards,
Micha Wiedenmann
[15 Jun 2015 10:29] Micha Wiedenmann
Testcase to show the influence of the shell parameter

Attachment: #70269 - testcase.py (text/plain), 1017 bytes.

[22 Sep 2017 11:47] Mark Anderson
This is still an issue  !!
[22 Sep 2017 11:49] Mark Anderson
Workbench 6.3

MySQL 5.6.37
[11 Dec 2019 7:56] Stian Skjerveggen
6 years later, and this is still an issue.