虽然以下的方法也可以解决，不过最简单直接的，还是直接在路径前后加双引号-" "，这个方法简单有效。
首先要说明的是mysqldump.exe在哪里不重要，重要的是要处理好路径中的非法字符。
比如：我的mysqldump.exe的位置在本地的
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ui\WEB-INF\data\test
直接调用肯定是不行的，因为路径中有空格。
解决方法是把空格换成
C:/Progra~1/Apache~1/Tomcat~1.0/webapps/ui/WEB-INF/data/mau
的样子。
这里分两种情况：
1、Program Files、Apache Software Foundation
类似这种的直接保留前六个字母，再加“~1”就行了
2、Tomcat 6.0 、tomcattomcat 6.0、tom 6.0、to 6.0
这个需要保留“.0”,最终换成Tomcat~1.0 、Tomcat~1.0 、tom6~1.0、to6~1.0
规律一看都能看明白。
最终处理结果如下：
C:/Progra~1/Apache~1/Tomcat~1.0/webapps/ui/WEB-INF/data/test/mysqldump.exe ...
其实以上就是所谓的DOS 8.3格式文件名规范。
所谓8.3格式短文件名规范，就是型如 PROGRA~1（目录）或者元素周~1.exe（文件）这样的名称——
“8”是指文件名或目录名的主体部分小于等于8个字节；
“3”是指文件名的扩展名部分小于等于3个字节。
另外还有一点，就是8.3文件名的有效字符不包括空格等特殊字符。
8.3短文件名格式规范是DOS+FAT12/FAT16时代遗留下的老规矩，自从Windows95开始（其实据说从Windows for Groups 3.11开始），Windows就已经能支持长文件名，但是为了向前兼容，特别是文件系统兼容性，FAT文件系统均强制执行“为长文件名提供8.3兼容格式的短文件名”的特性。
因此你会看到，在FAT16/32文件系统上：目录"program files"同时还拥有一个8.3规范的"PROGRA~1"短名称；而文件"元素周期表.exe"也同时拥有一个"元素周~1.exe"的短名称。[这有一点像类UNIX系统下的hardlink，一个对象拥有两个引用方式。]
PS：知道为什么IE浏览器的主程序叫做iexplore.exe 而不是iexplorer么？就是为了照顾8.3短文件名规范。
===================NTFS文件系统与8.3格式规范的兼容性===================
NTFS文件系统支持unicode（UTF16）字符集文件名，最长达255个UTF16字符，因此NTFS文件系统以及基于unicode字符集的32位NT内核Windows操作系统本身都没有必要遵循16位DOS时代遗留的8.3格式短文件名规范。
但还是为了兼容性，NTFS文件系统也提供了一个可选的特性：8.3兼容格式。Windows中这个特性默认是on，也就是说每当建立一个长文件名的对象的同时，系统的NTFS驱动模块会自动建立一个合适的8.3格式短名称指向这个对象。
需要指出的是，这个特性并不像FAT文件系统中那样是强制执行的，因此不同的磁盘实用程序或者操作系统可能有不同的执行方式——
比如windowsXP中可以用 fsutil behavior set disable8dot3 1 命令关闭，驱动模块关闭这一特性后就不会每次都额外地建立一个附加的短名称，这样在新建/重命名大量小文件/目录的时候能略微提升磁盘的写入速度，（不用计算出一个合适的短文件名，也不用把这个额外的信息写入磁盘）。
=================非win32标准的老程序兼容性依赖8.3规范=================
但是，关闭这一特性之后可能导致某些古老的应用程序出现兼容性问题，这些程序虽说是32位GUI界面的“windows应用程序”，却不完全遵循win32程序的规范，而是通常混合有16位API，使用8.3格式短名称来引用文件。很显然，如果在一个NTFS分区上根本就不为长文件名提供短名称，那么这些16/32位混合型老程序将无法用8.3格式短名称来找到文件，当然会出错……但是事情并不总是这么简单的——
最近我发现有几个老的应用程序不能正常启动，这包括曾经在科大校园网上非常流行的科技大词典（主程序 ncce_win.exe，怎么样，熟悉不？）细查原因，似乎只是放在NTFS分区才会出问题，移到FAT32的U盘上没问题。后来我惊讶的发现：把U盘格成NTFS再放上这个程序也没问题！…… ……
数小时后，真正的的原因被找到了，说起来非常复杂，简而言之：全路径上有一级目录不兼容短文件名格式，因此主程序找不到相关文件！
为什么会有一级目录不兼容8.3规范呢？
因为我的硬盘是在以前的硬盘出故障后新换的，换上来之前，我在一个64位windows操作系统上把旧硬盘上还能读出的目录一一复制过来，而那个64位windows关闭了NTFS的8.3兼容特性，复制来的目录和文件都不具备附加的短名称，特别是我放应用程序的E:\program files\目录。（64位windows理论上是完全不支持16位和16/32位混合程序的，因此可能默认就关闭了NTFS驱动的8.3兼容性，或者也许是什么优化程序关闭的。）
然后我用GHOST恢复了系统分区，恢复的32位winXP并没有关闭8.3兼容性，但关键问题是已经写入NTFS分区的（不具备短名称的）目录和文件并不会被这个32位XP重建短文件名，系统只会对新建的文件或目录附加8.3文件名，至于原先已经建立好的目录和文件，即使是重命名这种操作，也无法“提醒”XP检查并追加上一个短文件名——这一点让我百思不得其解。
于是，当我把软件放在E:\program files\的子目录中时，虽然子目录“科技词典”，以及ncce_win.exe等文件名都符合8.3规范，但是全路径上有一个“program files”是不符合8.3规范的，并且没有等效的短名称代替，所以某个API就无法用“E:\progra~1\科技词典\xxxxxxxx.xxx”定位文件了，这个程序当然无法正常启动。
-----------------------与8.3兼容名称相关的一些命令-----------------------
fsutil behavior query disable8dot3 检查NTFS驱动是否开启8.3兼容特性
fsutil behavior set disable8dot3 1 关闭8.3兼容特性
fsutil behavior set disable8dot3 0 开启8.3兼容特性
fsutil file setshortname <longname> <8.3name> 手工指定一个8.3短名称
dir /x 列出当前目录的子目录和文件，以及相应的8.3兼容名称（如果有的话）
---------------------------------------------------------------------------------------------------------
Windows 关闭、开启短文件名功能：
打开注册表，找到：HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
将 NtfsDisable8dot3NameCreation 的值设为 1，也就是不创建短文件名，具体含义如下：
0 NTFS creates short file names. This setting enables applications that cannot process long file names and computers that use different code pages to find the files.
1 NTFS does not create short file names. Although this setting increases file performance, applications that cannot process long file names and computers that use different code pages might not be able to find the files.
---------------------------------------------------------------------------------------------------------
GetShortPathName 得到长文件名对应的8.3格式的短文件名
当Windows进入长文件名时代，因此dos时代的8.3格式文件命就派不上用了， 但是有些时候8.3格式文件名却很有用，例如当一个word的文件名有空格时，要用shell的方式打开word文件时，word就把文件名当中的空格截掉，导致文件打开会失败，解決方法就是用GetShortPathName讲长文件名转换为短文件名。
例如：
GetShortPathName (L"C:\\Documents and Settings\\All Users", szOut, sizeof(szOut));
返回C:\DOCUME~1\ALLUSE~1
具体说明在：http://technet.microsoft.com/en-us/library/cc959352.aspx