I have the following line in a new install script which is designed to create a backup for the end user and not actually install anything.

Zip Files from "C:\ProgramData\CMS APPS\SIR\*.*" to "C:\CMS APPS\BKUP\SIR\SIRBKUP.ZIP" [Recurse]

All of the folders listed in the line already exist, having been placed there by the earlier install program. The install kept blowing up with an error about not being able to locate "APPS\SIR" but it did produce a zip file. The zip file contained ALL the folders under ProgramData, not just the specified one.

Note that the destination folder path contains a space ("C:\CMS APPS\BKUP\SIR\SIRBKUP.ZIP") and that does not cause an error message.

Next I renamed the "ProgramData\CMS APPS" folder to "ProgramData\CMSAPPS" (no spaces) and changed the line of code in the script to also not use a space on the source folder.

It worked!

Is this a bug or WAD (Working As Designed)? Seems peculiar that the destination is OK with spaces in the folder paths, but the source is not... In XP, Vista and Win7 spaces are very common in folder paths.

I have not had time to test the unzip function to see if it allows spaces in the source and destination paths. Maybe tomorrow.

One other interesting thing, not a bug but something I need to remember. When doing a zip using the name and path of an existing zip, new files are added to the existing zip. Interestingly, if a particular data file that was zipped earlier is removed from the user's machine and the zip is built using the exact same path and file name, the "old" file is not removed from the zip file. That actually could be a very handy feature if a customer accidentally deletes a data file and then does a backup. The missing file would still be in the zip file and could be recovered. That's a Good Thing!

CMS