[Bug]: The process cannot access the file because it is used by another process.

[OfficialEsco]

Brief description of your issue

Found a issue when i wanted to update the metadata for Oracle.JDK.17
I've found no workaround for the issue, wingetcreate does not have this issue.

Steps to reproduce

Option 1, 2 or AutoUpdate

PackageIdentifier: Oracle.JDK.17
Version: 17.0.1.0 (AFAIK it does not matter)
Url: https://download.oracle.com/java/17/latest/jdk-17_windows-x64_bin.msi

Expected behavior

For it to work like any other update

Actual behavior

Get-FileHash : The file 'C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp' cannot be read: The process does cannot access the file C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp because it is used by another process.
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:805 char:50
+ ... erSha256'] = (Get-FileHash -Path $script:dest -Algorithm SHA256).Hash
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ReadError: (C:\Users\Esco....1.1.winget-tmp:PSObject) [Write-Error], WriteErrorException    
    + FullyQualifiedErrorId : FileReadError,Get-FileHash

Get-AppLockerFileInformation : The process cannot access the file because it is used by another process. (Exception from H
RESULT: 0x80070020)
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:808 char:41
+ ... e = [string]$(Get-AppLockerFileInformation -Path $script:dest | Selec ...
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-AppLockerFileInformation], FileLoadException
    + FullyQualifiedErrorId : TestAppLockerPolicyCmdlet-FailedProcessingFile,Microsoft.Security.ApplicationId.PolicyManage  
   ment.Cmdlets.GetAppLockerFileInformationCmdlet

Remove-Item : Cannot remove item C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp: The process does cannot access the file  C:\Users\Esco\AppData\Local\Temp\Oracle.JDK.17 v17.0.1.1.winget-tmp ecause it is used by another process.
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:844 char:13
+             Remove-Item -Path $script:dest
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\Esco....1.1.winget-tmp:FileInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand
The file could not be downloaded. Try running the script again
At C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:802 char:13
+             throw [System.Net.WebException]::new('The file could not  ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], WebException
    + FullyQualifiedErrorId : The file could not be downloaded. Try running the script again

Environment

Latest YamlCreate update as of 2021-07-17

PowerShell 5 Version          : 5.1.22000.65
PowerShell 7 Version          : 7.1.5

Windows Terminal Version      : 1.11.2921.0
Tabby Version                 : 1.0.159

Windows Package Manager Manifest Creator v0.4.1.1

[Trenly]

I can't quite seem to track down the source of this bug. It says that the array can't be null when doing File.Write, but the content isn't null when I try it outside of the script. I'll keep looking at this

[OfficialEsco]

Might be multiple issues

AFAIK it gets stuck on the download part but doesn't throw as expected
(-autoupgrade)

It will then throw the Error and cannot be deleted until pwsh is closed

(Option 1)

Selection: 1

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: Oracle.JDK.17

[Required] Enter the version. for example: 1.33.7
Version: 17.0.1.1
Found Existing Version: 17.0.1.0

[Required] Enter the download url to the installer.
Url: https://download.oracle.com/java/17/latest/jdk-17_windows-x64_bin.msi


Downloading URL. This will take a while...
Time taken: 17 second(s)
Get-FileHash: C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:429

(Throws error)

[OfficialEsco]

I guess this is what you saw?

Selection: 1

[Required] Enter the Package Identifier, in the following format <Publisher shortname.Application shortname>. For example: Microsoft.Excel
PackageIdentifier: Nvidia.CUDA

[Required] Enter the version. for example: 1.33.7
Version: 11.5
Found Existing Version: 11.3

[Required] Enter the download url to the installer.
Url: https://developer.download.nvidia.com/compute/cuda/11.5.0/local_installers/cuda_11.5.0_496.13_win10.exe


Downloading URL. This will take a while...
Time taken: 2 second(s)
Get-FileHash: C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:429
Line |
 429 |  …           $InstallerSha256 = (Get-FileHash -Path $script:dest -Algori …
     |                                                     ~~~~~~~~~~~~
     | Cannot bind argument to parameter 'Path' because it is null.

Get-AppLockerFileInformation: Cannot validate argument on parameter 'Path'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
Remove-Item: C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:443
Line |
 443 |  … ch '\.(msix|appx)(bundle){0,1}$')) { Remove-Item -Path $script:dest }
     |                                                           ~~~~~~~~~~~~
     | Cannot bind argument to parameter 'Path' because it is null.

OperationStopped: C:\Users\Esco\GitHub\winget-pkgs\Tools\YamlCreate.ps1:425
Line |
 425 |              throw [System.Net.WebException]::new('The file could not  …
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The file could not be downloaded. Try running the script again

[Trenly]

I see why it is misclassifying it as .winget-tmp in the autoupgrade, but that is minor.

I actually saw both, but I believe they are the same root cause. I think that with larger files, it isn't able to write them properly and terminates before closing the file stream. I'm wondering now if it wouldn't be better to just use the naming convention of $PackageIdentifier v$Version and try getting the extension. The primary reason for using the filestream was to preserve original file names if they existed. But, I don't know that its all that important to keep them

[vedantmgoyal9]

I think the error that occurred here is also related to this issue.

I think that with larger files, it isn't able to write them properly and terminates before closing the file stream.

Octopus Deploy's installer is 1.7 GB in size.

Edit: This run also failed at Octopus Deploy Server - https://github.com/vedantmgoyal2009/winget-pkgs-automation/runs/3983305585?check_suite_focus=true