I’ve got a DSC Configuration that uses two Archive resources.
the problem is that it appears the Archive resource is caching the destination path from the first resource, and using that for the second resource (resulting in an error).
I’m assuming I’m doing something wrong, but I do think it’s curious that the source code for MSFT_ArchiveResource does seem to have a cache, and I’m wondering if the hash logic for the cache is getting confused somehow.
I’ve been looking at the source code for the Archive resource. There is some caching behavior, but nothing that should be changing your destination argument, so far as I can tell. The cache is mainly there so DSC doesn’t have to download and process the zip file every single time it checks your configuration (unless the source’s last modified date attribute has changed.)
In order to troubleshoot further, I’d probably have to see the Archive resource lines from your configuration script, and any error messages that you’re getting.
Interesting - the second zip contains some sub-directories. It was created with 7Zip, and after editing the .zip by removing the subdirectories and then re-adding them it now works - so maybe it has something to do with how the .zip is formatted
Further experimenting and if I create the .zip files so that they contain a directory as the root object, then they extract fine (eg. there are no files at the top level inside the zip).
It’s working, but there’s definitely something unusual that happens sometimes - hard to know if it’s 7zip or the Archive resource which is the culprit.