-
Notifications
You must be signed in to change notification settings - Fork 905
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
Logging is broken in some packages due to new TEMP directory #813
Comments
For most of our popular packages, I've had to set $logfile to "$env:TEMP\chocolatey$($packageName).MsiInstall.log" |
Most native installers create log files simply as As for packages using TEMP\chocolatey (or TEMP\chocolatey), correct me if I'm wrong, but have those directories ever been actually documented? I believe they have not and packages putting log files there should be treated as relying on non-contractual implementation details. The package validator (or verifier? the one that performs the actual installation - I always confuse the two) could actually detect this and flag it as package error. To mitigate this situation, after performing the installation/uninstallation of a package, Chocolatey could scan the TEMP\chocolatey directory and move all .log and .txt files it finds to TEMP, with a warning. |
Unfortunately choco new generated out the default silent args with this - I disagree with the assessment to move the files with a warning - the The better service is to ensure the folder exists, overcoming a limitation And the Chocolatey subfolder of $env:TEMP (actual) is guaranteed to exist. On Saturday, June 18, 2016, Jakub Berezanski [email protected]
Rob http://codebetter.com/robreynolds |
Good point about TEMP being restricted in some environments. In that case, substitute (cacheLocation ?? TEMP) for TEMP in my recommendation. But wouldn't packages using TEMP\chocolatey as log path fail in these environments anyway? I agree that ensuring the folder exists is a simple and quick way to fix the issue without putting any burden on package maintainers. 👍 There is one ramification of leaving the logs in TEMP\chocolatey - the logs will be deleted in cases specified in 353c2da. This might be undesirable for some folks. In particular, this makes examination of the log generated during a successful uninstall impossible, as it will be immediately deleted. That is why I stand by my suggestion to move log files out of the package cache directory - perhaps to a new directory, |
@marcinbojko Right now that would be broken because $env:TEMP in package Please consider this a gating bug that will be resolved this weekend - no On Saturday, June 18, 2016, marcinbojko [email protected] wrote:
Rob http://codebetter.com/robreynolds |
@jberezanski When it comes to uninstall logs, folks are free to put that file where ever they want. We don't make any suggestions about where that should go. So if they put it in the package folder cache and it deletes it, that's really more on them to figure out. Perhaps a misinterpretation of my earlier comments? We only go down to TEMP\chocolatey with the $env:TEMP variable. The only other two times those log files would get deleted is just prior to forcing an install / upgrade, which those files would likely get overwritten anyway. In the case of the forced install, this is exactly the case. In the case of the forced upgrade, it's quite likely. BTW, using |
@ferventcoder , I figured out that much, but wanted ensure at least few working packages for my colleagues. |
0.9.10.2 is moving through the automated moderation process now. |
Make the default value that comes out of the template for logging use a much shorter path.
When using $env:TEMP in versions of Chocolatey less than 0.9.10.x, TEMP did not include "chocolatey". However, due to GH-590 and a9519b5, this is now causing issues when someone has setup an MSI logging file with `$env:TEMP\chocolatey\packagename\packagename.msi.log`. The package TEMP value evaluates to `$env:TEMP\chocolatey` (actual TEMP variable), which results in `$env:TEMP\chocolatey\chocolatey\packagename\packagename.msi.log`. This breaks because that folder doesn't get created. Instead look for double chocolatey folder in actual evaluation and handle that to ensure compatibility with packages.
* stable: (version) 0.9.10.2 (doc) update CHANGELOG/nuspec (GH-758) Ensure log path exists (GH-813) Fix double chocolatey logging folder (GH-813) Shorten Template default log path (doc) update default options help messages (maint) Don't log creation of folder (maint) formatting / add message consistency (GH-814) Ensure any version of choco (GH-811) Skip resource / licensed assemblies (version) 0.9.10.1 (doc) update CHANGELOG/nuspec (GH-810) Install of choco sets exit code (GH-812) Upgrade 7zip to 16.02 to address CVEs (doc) Note functions Calling Set-PowerShellExitCode (GH-810) Fix - Cannot bind parameter exitCode
For GH-813 (ae2e857), the double `chocolatey\chocolatey` folder was removed from `$silentArgs` and `$additionalInstallArgs`, but `$file` was missed. These changes were originally necessary due to changes in GH-590 (a9519b5). Ensure that $file is also set properly so it no longer uses a double chocolatey folder.
Due to #590, specifically a9519b5, this is now causing issues when someone has setup an MSI logging file with
$env:TEMP\chocolatey\packagename\packagename.msi.log
. We need to handle that situation.The text was updated successfully, but these errors were encountered: