Windows installer should use existing SFN paths when upgrading a system where SFN support has been disabled

[Brian Smith]

The Windows installer always creates the POPFILE_ROOT and POPFILE_USER environment variables. POPFile does not work properly if the paths stored in these variables contain any spaces. Therefore the installer normally uses the short file name (SFN) version of the paths when defining these variables (by default SFN support is enabled in Windows).

Sometimes SFN support gets disabled after POPFile has been successfully installed. This may cause a problem when an attempt is made to upgrade to a newer version of POPFile because the installer will refuse to install POPFile using a path which contains spaces (e.g. "C:\Program Files\POPFile") even though this is the location of the existing POPFile installation.

It would be more user-friendly for the installer to use the existing SFN path when it detects that SFN support is no longer enabled when upgrading an existing installation. When an existing installation is detected the SFN path could be displayed in the installer instead of the LFN one in order to avoid the "invalid path" error message.

[naoki iimura]

POPFile does not work properly when POPFILE_ROOT or POPFILE_USER contains white spaces because Perl's 'glob' function does not support the file path with white spaces.

I want to solve this problem in POPFile v2.

I guess we can use 'bsd_glob' function of File::Glob or 'glob' function of File::Glob::Windows instead of 'glob' to solve the issue:

• ​http://search.cpan.org/~jesse/perl-5.14.1/ext/File-Glob/Glob.pm
• ​http://search.cpan.org/~tate/File-Glob-Windows-0.1.4/lib/File/Glob/Windows.pm

Naoki