Get-ChocolateyUnzip / Start-ChocolateyProcessAsAdmin - can fail running a process when working directory is a UNC path #1781
Comments
|
Get-Location is used in a few other helper functions. Specifically:
However in these instances, because of the way that the working directory is used, it may be appropriate to assume that the working directory has been set. Would it be better to use a temp directory if it has not been set? In Get-ChocolateyUnzip however, the unzip "destination" is set independently of the working directory, and I don't see any other need for it. As a test, I commented out the line that sets the Process.StartInfo.WorkingDirectory (Get-ChocolateyUnzip.ps1:187) and found that the unzip process completes as expected. |
General-Fault
changed the title
|
With more logging I found that the working directory was not null, but rather was a UNC path (set by MDT). Updated title, description and log with this information. |
|
@General-Fault Thanks for logging the issue! This is actually something we've seen in other places. I think this is related to #1216 |
if ((Get-Location) -eq $null)
{
Write-Warning "Working Directory not set. Setting to '$env:ChocolateyInstall'"
Set-Location $env:ChocolateyInstall #See https://github.com/chocolatey/choco/issues/1781
}
if ([string]::IsNullOrEmpty((Get-Location)))
{
Write-Warning "Working Directory is an empty string. Setting to '$env:ChocolateyInstall'"
Set-Location $env:ChocolateyInstall #See https://github.com/chocolatey/choco/issues/1781
}
Write-Debug "Working Directory is now '$(Get-Location)'"Note: here's the only message that is produced.
Looks like you have your shell (powershell.exe) set to a file share. |
|
Which you mentioned already, just want to be sure I have all of the details outlined. |
ferventcoder
changed the title
ferventcoder
changed the title
ferventcoder
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This is fixed for v0.10.14. |
ferventcoder
added a commit
that referenced
this issue
May 30, 2019
Ensure when calling Get-Location, the FileSystem PSProvider is taken into account. Otherwise folks in a different PSDrive calling choco could cause unforeseen errors.
ferventcoder
added a commit
that referenced
this issue
May 30, 2019
When unable to set the working directory next to the installer, fall back to setting that directory to temp.
ferventcoder
added a commit
that referenced
this issue
May 30, 2019
Capture the current directory as part of the configuration, allowing it to be inspected in the logs later for issues that might occur.
ferventcoder
added a commit
that referenced
this issue
May 30, 2019
When seeing the following error: `ERROR: Exception calling "Start" with "0" argument(s): "The directory name is invalid"` this can stem off of permissions issues or an incorrectly formatted directory being passed. When using Get-Location, if that location is a UNC path, PowerShell shows that with `Microsoft.PowerShell.Core\FileSystem::\\server\share`, resulting in that entire string to be passed as the PATH for the working directory that is passed to `System.Diagnostics.Process.StartInfo.WorkingDirectory`. Unfortunately that doesn't evaluate to an acutal valid path, thus the error is produced. Instead, the path should be evaluated with ProviderPath, which removes the `Microsoft.PowerShell.Core\FileSystem::` from the actual path, resulting in a valid path using a UNC location. Also make a determination if the path is not set (such as with things that are run during provisioning) and provide a valid working directory using cache location.
ferventcoder
added a commit
to ferventcoder/choco
that referenced
this issue
May 30, 2019
* stable: (version) 0.10.14 (doc) update release notes (chocolateyGH-53) Interactive Prompt - allow short answer when "-" included (chocolateyGH-53) Confirmation - Allow Yes To All (doc) update release notes for 0.10.14 (chocolateyGH-1433) config: UpgradeAllExceptions (chocolateyGH-1781) fix: use ProviderPath for Get-Location (chocolateyGH-1781) capture current directory in config (chocolateyGH-1781) Fix: fallback to temp for working dir (maint) formatting (chocolateyGH-1781) Ensure Get-Location uses FileSystem (maint) formatting
|
The bugfix changes from this issue are causing further problems with packages which use The package in particular is teamcityagent where the installation script has the following lines at the end # TODO: catch failure and call chocolateyUninstall.ps1 or some other cleanup
Set-Location $agentDir\bin
Start-ChocolateyProcessAsAdmin "Start-Process -FilePath .\service.install.bat -Wait"
Sleep 2
Start-ChocolateyProcessAsAdmin "Start-Process -FilePath .\service.start.bat -Wait"The TeamCity agent is extracted to C:\buildAgent, and service.install.bat lives in C:\buildAgent\bin. During execution I'd expect I've found one workaround is to update the package installation code to the following: # TODO: catch failure and call chocolateyUninstall.ps1 or some other cleanup
$workingDir = Join-Path $agentDir "bin"
Start-ChocolateyProcessAsAdmin "Set-Location $workingDir; Start-Process -FilePath .\service.install.bat -Wait"
Sleep 2
Start-ChocolateyProcessAsAdmin "Set-Location $workingDir; Start-Process -FilePath .\service.start.bat -Wait"using the If this is intended behaviour this needs to be marked as a breaking change in v0.10.14 as this is not backwards compatible. |
|
This had additional fixes for 0.10.16 as #2051. Thanks for that @ifreislich! |
|
@ferventcoder any word on a 0.10.16-beta release? I just smashed headlong into this problem and I spent a couple hours fighting with it assuming that it was my package invocation arguments or something else in my environment, never once thinking it was a bug in Chocolatey's privilege escalation as that runs under the covers and the package was reporting it grabbed all the files correctly. |
|
@dragon788 hey man, long time no talk! I think we can set up for a beta for sure. |
|
It's rolling through moderation right now, but here you go - https://chocolatey.org/packages/chocolatey/0.10.16-beta-20200806 |
|
Great, thanks @ferventcoder ! I tried this out and I'm still getting some weirdness, but it might just be the sql-server-2019 install script giving me heartburn and not necessarily this bug. |
|
I had another run with The important bit seems to be here. This is the complete log from choco upgrade and refreshenv to installing the package. I'm going to try upgrading chocolatey in an earlier step and reboot and see whether that makes any difference due to fresh loading of DLLs or clearing system state in $TEMP. |
|
@dragon788 Here's your error: That's package specific. Looks like there is a bug in the package or the chocolatey-core.extension package - I would look to see about upgrading the chocolatey-core.extension package first and see if it resolves not getting the MountVolume. |
|
Having the same issue as @dragon788 when trying to
I am on the latest |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What You Are Seeing?
Chocolatey Version 0.10.13
Installing a package that calls 'Get-ChocolateyUnzip' fails when the working directory is a UNC path (such as with an MDT LTI Application installer). The error logged is:
What is Expected?
The package should be installed. A working directory is not necessary to unzip the file.
The WorkingDirectory can be left unset.
https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.processstartinfo.workingdirectory?view=netframework-4.7.2
How Did You Get This To Happen? (Steps to Reproduce)
\\servername\sharename\).choco install.Workaround
Set a working directory packages installation script before calling Get-ChocolateyUnzip.
Output Log
Full Log Output
get-chocolateyunzip-test.0.0.1.nupkg.zip
The text was updated successfully, but these errors were encountered: