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: | |
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
[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.