MySQL Bugs: #27546: spaces in RUNDIRECTORY and backint

Bug #27546	spaces in RUNDIRECTORY and backint
Submitted:	30 Mar 2007 11:57	Modified:	27 Sep 2008 10:34
Reporter:	Samo Dadela	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MaxDB	Severity:	S3 (Non-critical)
Version:	7.6.00	OS:	Windows (WIN32)
Assigned to:		CPU Architecture:	Any
Tags:	backint, path, spaces

Description:
When backint is invoked with the RUNDIRECTORY path passed to backint is split into multiple words. Instead of recieving just one argv[] for the path, you get as many argv[]'s as there are spaces in RUNDIRECTORY. 

When reporting status back to MaxDB from backint, MaxDB does not accept quoted (with " or ') paths. Example:
#BACKUP c:/My Documents/smthing -> maxdb will report an error, not recognising the path. 

Workaround: don't use a path with spaces. 

How to repeat:
Make new instance - use defaults. Don't change RUNDIRECTOY (the default is something like c:\Document And Settings\All Users\...). 
Make a backup medium (complete data, pipe, BACK). 
Backup - invoke backint (not the default one; make a new backintTST.EXE and change bsi.env to point to it). 
Dump argc and argv[] from backintTST.exe to a file. 
Result: The path is split (instead of one word, its split into multiple words). 

(I think the problematic flag is -i.)

Note: You could guess what the original path was... but if someone used two spaces in the path then this becomes impossible (c:\My<space><space>Database). 

Note: Tried to change the path from dbmcli and MaxDB GUI (DBMGUI) - no luck. 

Try also to report back the status of the BACKUP (maybe this can be entered as a separate bug, but I cosider it the same - MaxDB is not handling spaces/quotes properly). 

Suggested fix:
Quote the path before running CreateProcess(). Use "".

Suggested Fix: construct the argument vector correctly.

Hello Samo,
thanks reporting this. The SAP specification doesn't allow spaces in the path for the RUNDIRECTORY.
Nevertheless I agree with your suggestion. We have fixed that in other components too and have opened an internal changerequest to fix this in 
one of the next version.

You can watch the state with
http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1150516

Regards,
Burkhard

Thank you for a problem report. According to http://www.mysql.com/news-and-events/press-release/release_2007_40.html:

"support of the MaxDB database will revert back to SAP"

MaxDB is not under MySQL umbrella any more.