MySQL Bugs: #111567: no longer can write to drive

Bug #111567	no longer can write to drive
Submitted:	26 Jun 2023 18:07	Modified:	27 Jun 2023 20:01
Reporter:	Rick Tilley	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: mysqldump Command-line Client	Severity:	S7 (Test Cases)
Version:	8.0.33	OS:	Windows (Microsoft Windows 10 Pro)
Assigned to:		CPU Architecture:	x86
Tags:	WBBugReporter

Description:
I use mysqldump.exe that comes with MySql Workbench.  This is called from DataGrip, but I can also get the same error running the command in powershell:

mysqldump.exe ebdb --result-file=C:\t\dumps --user=mysqladmin --host=slaormysql.xxxxxxxxxx.us-east-1.rds.amazonaws.com --port=3306

I have tried various directories, and given all users full directory access, I get the same error regardless.  This was working the last time I used it, but a few months later and now it's broken of it's own accord.

mysqldump: Can't create/write to file 'C:\t\dumps' (OS errno 13 - Permission denied)

How to repeat:
Attempting to do a dump of either my local dev MySql db or remote production MySql db.  I can refresh and query the DBs, but doing a data dump gives me the create/write file access error.  I have tried various troubleshooting, including rebooting, uninstalling/updating MySQL Workbench to latest version, using admin powershell, opening directory security access / read-only / write permissions.  This was working fine last month, the last time I worked on this.

This appears to be an authentication issue, although the error message is misleading.  I did get the dump to work this way:
C:\t\dumps> & 'C:\Program Files\MySQL\MySQL Workbench 8.0\mysqldump.exe' ebdb --user=mysqladmin --host=slaormysql.xxxxxxxxx.us-east-1.rds.amazonaws.com --port=3306 --password > c:\t\dumps\test.sql

Enter password: ****

And entered in the password manually.  Usually this is taken care of by the application, probably DataGrip is storing the password, I do not recall using a key to authenticate.  Any suggestions on the password auth issue / error message?  I still get the same error when I run the application the way DataGrip intends:

C:\t\dumps> & 'C:\Program Files\MySQL\MySQL Workbench 8.0\mysqldump.exe' --password --result-file=C:\t\dumps\ --user=mysqladmin --host=slaormysql.xxxxxxxxx.us-east-1.rds.amazonaws.com --port=3306

mysqldump: Can't create/write to file 'C:\t\dumps\' (OS errno 2 - No such file or directory)

I was able to get the command working using the --result-file setting instead of redirecting to a file.  This appears to be completely an issue of DataGrip not passing passwords to mysqldump.exe.  I still do not understand why I get the file write error instead of an mysql authentication error.

On further testing, I don't believe it's missing the password.  When I set --result-file=anyfile.sql it works, given that the login is successful.  However, when I set it to a path, such as --result-file=C:\t\dumps , I get that error.  I was able to have DataGrip do the dump just now using --result-file=C:\t\dumps\testagain .. However in this case, it creates a file called testagain.  Whereas before it would create a file such as MySQL___ebdb_slaormysql_xxxxxxxxxx_us_east_1_rds_amazonaws_com-2023_05_18_15_51_56-dump.sql.  Somehow the command line parameters between DataGrip and MySqlDump must have lost fidelity.  I'll keep looking over the command line parameters and will work with JetBrains to see what changed and what needs to change.

My apologies, it appears this all started due to me changing the out path in DataGrip and having my file replacement patterns erased without noticing.  I figured out how to restore the file replacement pattern and things are working correctly again.  This in part was due to an improper error output on mysqldump.exe's behalf, and DataGrip labeling the field out path, not out file.  Mostly it was this user's reliance on GUI and not noticing a field value was wiped out in the GUI.

Hello!

Thank you for confirming issue is no longer seen.

Regards,
Ashwini Patil