Get-ChocolateyUnzip captures files that don't belong to the package

[Erlkoenig90]

Under some conditions (probably on fast computers with slow storage), Get-ChocolateyUnzip and Write-FileUpdateLog capture files that don't actually belong to the package, list them in the chocolatey\libInstall.zip.txt file, and cause them to be removed upon uninstall via UnInstall-ChocolateyZipPackage. This can remove arbitrary files from the users' computer!

I think this happens when you install multiple packages, and the files created by the previous package don't appear immediately in directory-listings (i.e. Get-ChildItem in Write-FileUpdateLog), but do appear when the next package has been unzipped completely, and then get listed as belonging to that package. This of course only applies, if the $locationToMonitor for Write-FileUpdateLog contains other files that don't belong to the package, which happens in scenarios where multiple packages install files into the same directory, like plugins for an eclipse installation or a UNIX-like directory structure (e.g. Cygwin, MinGW).

I think it's generally a bad idea to monitor the file system for changes to find out what files are created by 7-Zip, because other applications might modify files and big directory trees might get scanned (possibly related: #154 ).

I made a fix for Get-ChocolateyUnzip that captures 7z's standard output to determine the files created by it, and record them in the Install.zip.txt . This should always precisely capture the unzipped files and might even be faster. The stdout is printed via Write-Debug. I will submit a pull request once i figure out how to use GitHub :-)

[ferventcoder]

I would love that behavior adjusted in a better way. The original behavior was brought in as a way to naively handle the idea of impact, but a more deterministic behavior would definitely be warranted!