Error in vcpkg_download_distfile.cmake renaming temp dir (may be docker-related)

[rleigh-codelibre]

Package: xerces-c:x64-windows
Vcpkg version: 0.0.113-nohash

I don't think the issue is really in xerces-c. It happens most frequently when running multiple "vcpkg install" commands in separate docker RUN steps. However, I have also reproduced by hand trying to install xerces-c.

The system is a VMware virtual machine running Windows Server 2016 (MSDN licence), running VS2015 in a docker image. The docker image is created from here and here. Could the filesystem behaviour under docker be part of the problem?

See e.g. this build log

Building package xerces-c[core]:x64-windows... 
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:74 (file):
  file RENAME failed to rename

    C:/vcpkg/downloads/temp

  to

    C:/vcpkg/downloads/temp0

  because: No such file or directory

Call Stack (most recent call first):
  scripts/cmake/vcpkg_from_github.cmake:108 (vcpkg_download_distfile)
  ports/xerces-c/portfile.cmake:19 (vcpkg_from_github)
  scripts/ports.cmake:71 (include)

I can't see any problem with the logic in the script; it's failing, but that shouldn't be possible. It should only try to rename the directory if it exists, so this condition should not occur.

[NancyLi1013]

Hi @rleigh-codelibre, thanks for posting this issue. Does this issue still exist on your machine now? I can't reproduce it.

[rleigh-codelibre]

Please see this build log which I ran just now to retest. The problem showed up almost immediately.

Edit: this used cached docker layers; I'm re-running and will update here once it's completed.

Retry failed building python. That's a separate issue.

I have now had success with this build but Xalan failed. I'll investigate that further.

I've seen the issue with quite a few other packages in addition to xerces; I don't think there's anything specifically wrong with the package, and I suspect Docker might be part of the problem, since I've never encountered it on a Windows virtual machine. I'll continue to investigate.

[rleigh-codelibre]

Aha, I've reproduced the problem here. You can see the rename bug hits while trying to build the Boost libraries.

[lsparey]

There's a few others having the same error #3399

[ZbigniewRA]

This bug is reproducible in docker quite consistently (#7079 has some more details on it). May I suggest removing "needs-repro" label?
I would also like to mention that this bug is most likely different than the main topic of #3399 (as that one seems to be Windows related, not docker related).

[cgorshing]

I can also consistently get this to fail as well following a jsoncpp install. As I'm building a new docker image, we are doing a git clone from github, so the following is using HEAD from github:

....... (bunch of prior logs) ......

Total elapsed time: 30.8 s

The package jsoncpp:x86-windows-static provides CMake targets:

    find_package(jsoncpp CONFIG REQUIRED)
    target_link_libraries(main PRIVATE jsoncpp_lib_static)

Removing intermediate container fa89076592f7
 ---> 214c35bf8d36
Step 27/30 : RUN	vcpkg install openssl:x86-windows-static
 ---> Running in d7d18e7a2867
The following packages will be built and installed:
    openssl[core]:x86-windows-static
  * openssl-windows[core]:x86-windows-static
Additional packages (*) will be modified to complete this operation.
Starting package 1/2: openssl-windows:x86-windows-static
Building package openssl-windows[core]:x86-windows-static...
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:79 (file):
  file RENAME failed to rename

    C:/tools/vcpkg/downloads/temp
  to
    C:/tools/vcpkg/downloads/temp0

  because: No such file or directory

Call Stack (most recent call first):
  scripts/cmake/vcpkg_find_acquire_program.cmake:267 (vcpkg_download_distfile)
  ports/openssl-windows/portfile.cmake:13 (vcpkg_find_acquire_program)
  scripts/ports.cmake:74 (include)
Error: Building package openssl-windows:x86-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: openssl-windows:x86-windows-static
  Vcpkg version: 2019.07.18-nohash

[Pospelove]

Same problem. See my steps to reproduce in #7997

[rleigh-codelibre]

I wonder if vcpkg should always remove both the temp and temp0 directories during every invocation. This would mean that when overlays are used, both will be created on the same overlay and so there will be no possibility of cross-device links when doing the rename.

Of course, it does beg the question of why cross-device links are being created in the first place. I thought the whole point of the overlays was to abstract this away so you got a filesystem which worked as usual despite it being comprised of several layers. Rename operations are hardly atypical, so it's interesting that vcpkg is triggering this condition where other tools are not.

[vicroms]

@rleigh-codelibre can you confirm whether the changes in PR #8032 fix the problem?

[rleigh-codelibre]

I'll test this tomorrow.

[cbezault]

@rleigh-codelibre ping

[rleigh-codelibre]

Still testing this, but you can see the results so far here:

• Repro of original fault

• Rebuild of container with test vcpkg branch; timed-out later on, will be tested properly below:

• Python build failure; maybe hitting on the same issue inside Python

• HDF5 build failure; again may be hitting the same issue inside the package build

• Qt5 build failure

So on a positive note, I can't reproduce the original failure with this PR. It does successfully build a large number of packages.

On the negative side, a number of packages fail to build which would otherwise build without problems on a native Windows installation, but don't work inside Docker. It might all be related to issues with the windows-filter storage driver. It's not necessarily vcpkg at fault here, but it does represent a significant usability gap with native Windows containers.

[codars]

Having same problem, any workaround?

[kafeg]

I have the same trouble inside my Docker environment. The dirty fix can be like that: change file scripts/cmake/vcpkg_build_make.cmake and insert there execute_process(COMMAND sleep 5) after file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}_tmp").