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:Microsoft Windows (WIN32)
Assigned to: CPU Architecture:Any
Tags: backint, path, spaces

[30 Mar 2007 11:57] Samo Dadela
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 "".
[30 Mar 2007 12:03] Samo Dadela
Suggested Fix: construct the argument vector correctly.
[11 Sep 2007 15:30] Burkhard Diesing
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
[4 Oct 2007 17:04] Valeriy Kravchuk
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"
[27 Sep 2008 10:34] Konstantin Osipov
MaxDB is not under MySQL umbrella any more.