Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Gary Ewan Park
@gep13
What are the exact steps that you are taking to see the things that you are seeing? If you delete a file during the chocolateyInstall script, it shouldn’t be put back in place. Can you publish provide a complete script that is having the problems that you are seeing, with an exact set of steps to reproduce?
Starz0r
@Starz0r
It's more of a problem with the behavior of how Chocolatey works
Chocolatey clears the tools folder of a package by copying it to lib-bkp, and restoring it once the script has fully ran
I find this an issue because, one of my packages just builds up folders of unzipped archives, which may or may not be a problem in the future.
Which, I'd like to fix by pushing an update to the package that clears this folder either during or after the script has fully ran successfully.
Gary Ewan Park
@gep13
Again, if you can provide what I have asked for, I or someone else, am an attempt to replicate the problem.
Starz0r
@Starz0r
Generate some garbage folders in lib/dust/tools/
Run ChocolateyInstall.ps1
https://paste.rs/TdA.podspec
Gary Ewan Park
@gep13

@Starz0r these are the steps that I have taken:

  • spun up a new instance of the chocolatey-test-environment - https://github.com/chocolatey-community/chocolatey-test-environment
  • cloned your repository - https://github.com/Starz0r/ChocolateyPackagingScripts
  • replaced the chocolateyInstall.ps1 file in the src/templates/dust/tools folder with the contents of the gist that you provided - https://paste.rs/TdA.podspec
  • Modified the version element in the nuspec to be a valid version number
  • Downloaded the required zip files from here: https://github.com/bootandy/dust/releases
  • Placed them into the src/templates/dust/tools folder
  • Run choco pack on the dust.nuspec file
  • Run the following choco install dust --source=".;https://community.chocolatey.org/api/v2"
  • Watched the installation - which was successful
  • Checked the contents of the c:/programdata/chocolatey/lib/dust folder
  • It didn't contain any zip files, which is expected, and instead, contained only the chocolateyInstall.ps1 file and the extracted zip file in a folder

If these aren't the steps that you are taking, can you please provide an alternative set of steps to illustrate the problem that you are seeing.

Starz0r
@Starz0r
@gep13 What was in /lib/dust/tools/?
Gary Ewan Park
@gep13
I mentioned that already... just the chocolateyInstall.ps1 file, and the extracted zip file
Starz0r
@Starz0r
You said you checked /lib/dust/ but the issue is in /lib/dust/tools
Unless you were implying you checked the entire tree
Then that's my bad
Gary Ewan Park
@gep13
Yes, the latter
There are no zip files in any of the folders within the lib/dust folder
Starz0r
@Starz0r
The only difference here is that I did not use a test environment, rather two actual machines, and in both cases the previous installations were not cleared out
My only clue is maybe having a file in the folders that are marked for deletion, don't get deleted because they contain a file.
As of now, the testing does not seem to match up with what is actually/should be happening.
The script you ran was actually pushed to an actual Chocolatey package, and in my case, did nothing to alivate the issue
Gary Ewan Park
@gep13
To be clear here, I didn't have a previous installation. This was a fresh installation of the dust package.
Starz0r
@Starz0r
@gep13 The additional folders get built up in tools after updates
Which is why I said you need to put some folders in there, possibly with some empty files, just to see if they'll get deleted
Gary Ewan Park
@gep13
The issue seems to be with the deletion of the folder. I added the following:
2021-09-26_07-49-58.png
And the result is this:
2021-09-26_07-49-47.png
i.e. the previous installation folder is never being removed
That would explain why the previous folders are building up
Starz0r
@Starz0r
0.6.2 is on the list isn't it?
Gary Ewan Park
@gep13
I don’t know what that means, sorry.
Starz0r
@Starz0r
I was talking about the Write-Warning, but it that doesn't mean anything because it's just iterating through the list
Looks like Test-Path is failing see that item as a folder?
Gary Ewan Park
@gep13
Yes, that is my assumption at this point.
Starz0r
@Starz0r
I'm not really sure how, since it literally is the type it's looking for
What happens if you Write-Warning the Test-Path check?
Starz0r
@Starz0r
Tried it myself, it just writes false for all entries
Gary Ewan Park
@gep13
@Starz0r try the following...
# cleanup
ForEach ($Installation in $PrevInstallations) {
    if ($Installation.PSIsContainer) {
        Remove-Item -Recurse $Installation.FullName
    };
};
Remove-Item ($ToolsPath + '\*.' + 'zip');
Notice the usage of PSIsContainer, and also the usage of .FullName
Otherwise, the attempt to delete the directory usages a relative path, which likey won't exist
This didn't show up until I remove the -EA 0
Once you know this is working as you expect it to, you can add that back in again
The relative path might actually explain why the Test-Path didn't work
Gary Ewan Park
@gep13
Yip, this was the issue. Using this works:
# cleanup
ForEach ($Installation in $PrevInstallations) {
    if (Test-Path -Path $Installation.FullName -PathType Container) {
        Remove-Item -Recurse -Force $Installation.FullName;
    };
};
Remove-Item ($ToolsPath + '\*.' + 'zip');
Again, you can add the EA back in, once you have tested things out.
@Starz0r ^^
Starz0r
@Starz0r
@gep13 As soon as you posted the first snippet I went to go check it out
When I realized it worked, I went to see if it was also the .FullName suffix that fixed it, and of course it was
Not sure why, since I thought scripts were executed in the tools folder, so how this could be a problem is beyond me
Thank you so much for the help