Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Erlkoenig90 opened this issue Feb 8, 2016 · 1 comment
Closed
Assignees
Labels
Milestone

Comments

@Erlkoenig90
Copy link
Contributor

@Erlkoenig90 Erlkoenig90 commented Feb 8, 2016

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 :-)

Erlkoenig90 added a commit to Erlkoenig90/choco that referenced this issue Feb 8, 2016
Sometimes, Install-ChocolateyZipPackage and Get-ChocolateyUnzip capture
files that don't belong to the package, record them in the
<packagename>Install.zip.txt file, and cause them to be removed upon
uninstallation by UnInstall-ChocolateyZipPackage. This fix uses 7z's
standard output instead to determine which files belong to the package.
This also avoids scanning possibly large directory trees.
@ferventcoder

This comment has been minimized.

Copy link
Member

@ferventcoder ferventcoder commented Feb 8, 2016

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!

@ferventcoder ferventcoder self-assigned this Feb 8, 2016
@ferventcoder ferventcoder added this to the 0.9.10 milestone Feb 8, 2016
@ferventcoder ferventcoder added 1 - Ready and removed 0 - Backlog labels Feb 8, 2016
Erlkoenig90 added a commit to Erlkoenig90/choco that referenced this issue Feb 8, 2016
Only print 7z's stdout in verbose mode, buffer the file list while
writing to <packagename>Install.zip.txt, and don't create that file at
all if the archive was empty.
@ferventcoder ferventcoder added 2 - Working and removed 1 - Ready labels Feb 11, 2016
@ferventcoder ferventcoder added 3 - Done and removed 2 - Working labels Feb 11, 2016
ferventcoder added a commit that referenced this issue Feb 11, 2016
Sometimes, Install-ChocolateyZipPackage and Get-ChocolateyUnzip capture
files that don't belong to the package, record them in the
<packagename>Install.zip.txt file, and cause them to be removed upon
uninstallation by UnInstall-ChocolateyZipPackage. Instead use 7z's
standard output to determine which files belong to the package.
This also avoids scanning possibly large directory trees.

This also resolves GH-476 by suppressing 7z's output as verbose.
ferventcoder added a commit that referenced this issue Feb 11, 2016
* pr617:
  (maint) comment cleanup
  (GH-526) set messaging to output as error
  (GH-520) Debug/Verbose should be global scope
  (maint) formatting
  (GH-616) Deterministicly capture unzipped/extracted files
ferventcoder added a commit that referenced this issue Feb 11, 2016
* stable:
  (maint) comment cleanup
  (GH-526) set messaging to output as error
  (GH-520) Debug/Verbose should be global scope
  (maint) formatting
  (GH-616) Deterministicly capture unzipped/extracted files
ferventcoder added a commit that referenced this issue Sep 14, 2016
When using a 32-bit version of 7z.exe to install applications, it can
be subject to file system redirection. This was originally handled
since 0.9.8.24 with
chocolatey-archive/chocolatey@54985d5
but was later accidentally reverted in choco v0.9.10 - GH-616
(bde0941).

With redirection, calls in 32bit processes to C:\Windows\System32 are
automatically redirected to C:\Windows\SysWOW64. This can have
undesirable effects when the path is meant to look for System32.
Windows provides `SysNative` for this reason, and it should be used if
the path is found (32bit processes on 64bit Windows). This puts the old
behavior back to how it worked prior to the changes in 0.9.10.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.