Closed Jcw87 closed 2 years ago
I can't reproduce this issue in my side, I used vcpkg 2022-03-09-1affd32f93b299d5a907816c328ca3ededb73a7e and VS2019 16.11.11. I'm not sure if your disk has access rights, does this issue also occur on other drive?
I've created several vcpkg installs and tried to replicate this again, both on my C drive (SSD) and my D drive (spinning magnetic disk). Most of the time, it would not happen. On a few occasions it did. I'm not sure what I did differently when the problem happened. There must be more steps critical to reproducing the issue that I'm not aware of. When I created this issue, the listed steps were all that was needed.
Among the various additional things I was trying:
I suppose I'll list everything that I was doing with my main vcpkg install in the past few days. Starting point was commit 30a3d841d88dbf1e668d875bcfc050aacdedc63b, with several libraries installed: x64-windows version of boost, zlib, and some others x86-windows version of zlib and some others
Did you install cmake locally? If so, could you please remove it before trying to reproduce this issue?
Thanks for posting this issue. If this issue has new information, please reopen it.
This happened to me again today, just as consistently as before. I deleted my packages, and went to re-install some of them, and the issue started up again. I currently suspect a bad interaction with the TortoiseGit shell extension. I really don't want to delete my packages again to test this hypothesis right now, though. I've had too many frustrating software annoyances today, including a Visual Studio compiler bug. I'll re-open the issue if I find out something more substantial.
vcpkg will often fail to install a package because it fails to create a directory that already exists.
Environment
To Reproduce
Alternately:
Expected behavior A build script should never fail because it can't create a directory that already exists.
Failure logs