Support streaming hashes #747
Comments
|
Please submit the gist of the chocolatey log output. Then we can look from there. |
|
Trying to determine where the actual issue occurs - more explanation: We only warn if we can't compute a hash. If you are seeing an error that is something else entirely. |
|
Roger... looking further in the long and we found the reason the install failed. It would be nice if streaming hashes were supported though... |
|
Was it a reason we could correct or is it something else? |
ferventcoder
changed the title
|
@ferventcoder was there ever any progress made on this? I am also having trouble deploying a package that is larger than 2GB with the same hash error, see the attached log file. |
|
Error or Warning? |
|
Its listed as a warning, but causes the package installation to fail. |
|
Looks like warning And then I see the package fails. I see the package fails afterwards. Can you open up the chocolatey.log instead of the chocolatey.summary.log and include that output instead? We'd need all of that to determine whether that is really causing the issue or not. Thanks! |
|
Debug output is going to be much more helpful. |
|
I have exactly the same problem with a package larger than 2GB. Console Output: Although chocolatey says that |
|
@ferventcoder any news about this issue? |
|
@KurtTheBerner I just reviewed your log, and the installation was successful for the package, but maybe not the software you were attempting to install. Perhaps there was some issue in the install-cmd for the software, but it did not report the error correctly back to to the powershell script which did not fail. Looking at https://gist.githubusercontent.com/KurtTheBerner/6efdf08cbcac24a1f4ee2d28323383c0/raw/2522ba1cadfe8f6c11afd1f0e731661d21411ee1/chocolatey.log, you will see it reports the package install as successful, and it does see all of the files when it goes through and runs the checksums for the files (after the powerShell script runs). Finding the files and reporting success means the package installation was successful. I would spend a closer look at the actual thing the installer is calling to see how it is not installing the software itself. Here is the script you are running: <#
==============================================================================
FILE : $chocolateyInstall.ps1 $
PROJECT : Install Script Library
COPYRIGHT: Copyright (c) myCompany
PURPOSE :
COMMENT :
------------------------------------------------------------------------------
HISTORY (latest entry first):
2012-03-22 Version 1.0
==============================================================================
#>
$ErrorActionPreference = 'Stop'
$packageName = 'My big Package'
$toolsDir = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)"
$logDir = $env:ALLUSERSPROFILE + "\MyCompany\InstallLogs\"
$logFileName = $logDir + "$packageName.log"
& $toolsDir\SQL-Install.cmd | Out-Null
Copy-Item -Path "$env:ProgramFiles\Microsoft SQL Server\120\Setup Bootstrap\Log\summary.txt" -Destination "$logDir\$packageName.log"As you can see from the log, it finishes running that without any reported issues: Since you are copying the log from the software install, I would take a closer look at that to see what errors it ran into. That's where you are going to likely find the issue. HTH |
|
Calling a .cmd file may not produce an exit code like you want, but you can always check LastExitCode to see if it errored on install. |
|
@ferventcoder I found the issue, the installation was cancelled and the ExitCode was not reported correctly. This warning has irritated me and I thought the problem is caused by this Warning and prevents me from looking deeper in my Code. |
Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
…files Previously, when getting the checksum of a file, this read the file into a byte array to pass to ComputeHash. However, this was limited to files of 2gb or less, and was not efficent memory wise. This changes the method to using a filestream which is passed to ComputeHash, which should allow arbitrary file sizes with better memory usage. The unit test for this method had to be removed because the mock filesystem does not allow opening a file stream.
What You Are Seeing?
Installing large packages fail when file size is larger than 2GB.
When looking at CryptoHashProvider, it appears it reads the entire file into memory and then compute the hash, and then throw the byte[] away.
It would make sense to change the IHashAlgorithm/HashAlgorithm to handle
IO.Stream.What is Expected?
The ability to install large packages.
How Did You Get This To Happen? (Steps to Reproduce)
Build a large nupkg and install via chocolatey.
Output Log
The text was updated successfully, but these errors were encountered: