AppSnap 1.3.3 deletes other programs when installing a application that begins with "n"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. add a setting below to userdb.ini

[ngrep]
category = Development:Libraries
website = http://ngrep.sourceforge.net/
describe = Network Sniffer
scrape = http://ngrep.sourceforge.net/download.html
filename = ngrep-#VERSION#-win32-bin.zip
version = ngrep-(\d+(?:\.\d+)+)-win32-bin\.zip
upgrades = true
download = http://ncu.dl.sourceforge.net/sourceforge/ngrep/

This setting cause deletion of all files in %PROGRAMFILES%. Don't try it
actually.

2. execute appsnap -n ngrep -i

What is the expected output? What do you see instead?

exptected: ngrep is installed.
actual: ngrep is installed, but most files in %PROGRAMFILES% are deleted!

What version of the product are you using? On what operating system?

1.3.3

Please provide any additional information below.

I inspected the problem. Deletion of files occurs in process#unzip_file.

            # in:
            #   INSTALL_DIR: '#INSTALL_DIR#'
            # out:
            #   directory: 'C:\Program Files'
            directory = self.replace_install_dir(INSTALL_DIR)
(snip)
        if os.path.isdir(directory):
            # deletes 'C:\Program Files' !!!
            self.delete_tree(directory)

In process#replace_install_dir, re.sub replace r'\n' to '\n' and
config.expand_env returns first line of it.

        # in:
        #   INSTALL_DIR: '#INSTALL_DIR#'
        #   install_dir: r'C:\Program Files\ngrep'
        #   string: '#INSTALL_DIR#'
        # out:
        #   string: '''%ProgramFiles%
        # grep'''
        string = re.sub(INSTALL_DIR, install_dir, string)

        # returns 'C:\Program Files'
        return self.global_config.expand_env(string)

I tried to write a patch to fix the problem, but I've found that this
problem is already fixed at r202.

I really must beg of you to release 1.3.4.

Original issue reported on code.google.com by miau...@gmail.com on 15 Oct 2011 at 10:06

[GoogleCodeExporter]

> I tried to write a patch to fix the problem, but I've found that this
> problem is already fixed at r202.

I made a mistake. The problem is fixed at r203.

Original comment by miau...@gmail.com on 15 Oct 2011 at 10:10