Setup - ESP-IDF Tools 2.0 fails with exit code 1 at installation of mconf tools (IDFGH-1558)

[dlafont]

Installer fails with:
PermissionError: [WinError 5] Access is denied: 'C:\Users\dlafont\Dropbox\03-ESP-IDF\tools\mconf\v4.6.0.0-idf-20190628' -> 'C:\Users\dlafont\Dropbox\03-ESP-IDF\tools\mconf\v4.6.0.0-idf-20190628.tmp'

See attached log.

Setup Log 2019-07-23 #001.txt

----------------------------- Delete below -----------------------------

If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at esp32.com instead.

INSTRUCTIONS

Before submitting a new issue, please follow the checklist and try to find the answer.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.

1. Fill in all the fields under Environment marked with [ ] by picking the correct option for you in each case and deleting the others.
2. Describe your problem.
3. Include debug logs on the monitor or the coredump.
4. Provide more items under Other items if possible can help us better locate your problem.
5. Use markup (buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.

----------------------------- Delete above -----------------------------

Environment

• Development Kit: [ESP32-Wrover-Kit|ESP32-DevKitC|ESP32-PICO-Kit|ESP32-LyraT|ESP32-LyraTD-MSC|none]
• Kit version (for WroverKit/PicoKit/DevKitC): [v1|v2|v3|v4]
• Module or chip used: [ESP32-WROOM-32|ESP32-WROOM-32D|ESP32-WROOM-32U|ESP32-WROVER|ESP32-WROVER-I|ESP32-WROVER-B|ESP32-WROVER-IB|ESP32-SOLO-1|ESP32-PICO-D4|ESP32]
• IDF version (run git describe --tags to find it):
  // v3.2-dev-1148-g96cd3b75c
• Build System: [Make|CMake]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // 1.22.0-80-g6c4433a
• Operating System: [Windows|Linux|macOS]
• Power Supply: [USB|external 5V|external 3.3V|Battery]

Problem Description

//Detailed problem description goes here.

Expected Behavior

Actual Behavior

Steps to repropduce

1. step1
2. ...

// It helps if you attach a picture of your setup/wiring here.

Code to reproduce this issue

// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"

void app_main()
{
    
}

// If your code is longer than 30 lines, GIST is preferred.

Debug Logs

Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is *too* long.

Other items if possible

• sdkconfig file (attach the sdkconfig file from your project folder)
• elf file in the build folder (note this may contain all the code details and symbols of your project.)
• coredump (This provides stacks of tasks.)

[igrr]

Thanks for the report. This may be the same issue which was described in #3545 (comment). If this is the case, running the installer again may help.
Will investigate more.

[allvto]

Hello, I have the same issue with os.rename - PermissionErrror

Cleaning the registry with CCLeaner as mentioned in #3545 (comment) did not solve the issue.

Setup Log 2019-07-24 #016.txt

[igrr]

@allvto can you please check if this other suggested workaround helps? https://stackoverflow.com/a/55938363

[allvto]

I used another workaround based on this fixed the issue for me:

In idf_tools_fallback.py, I added in the function strip_container_dirs

for retry in range(100):
try:
os.rename(path, tmp_path)
break
except:
print "rename failed, retrying..."

This worked somehow

[heaptronix]

os.rename(path, tmp_path)
PermissionError: [WinError 5] Access is denied: 'C:\esp32\.espressif\tools\cmake\3.13.4' -> 'C:\esp32\.espressif\tools\cmake\3.13.4.tmp'

Installation has failed with exit code 1

i am also facing same problem, i have tried method of registry cleanup, disable recently opened folders
but still this problem persist.

kindly guide in this situation,

regards
sushant

[msysmilu]

Try uninstalling the driver that Windows installed by default. Worked for me.

[jgroman]

Currently installation still fails when using release/4.0 branch because idf_tools.py is unpatched there. After copying idf_tools.py from master branch installation finishes successfully.

[igrr]

Thanks for the reminder, we will backport the fix to release/v4.0.

[BlackCoffeeAR]

Renaming of cmake folder is still failing, also with 100 retries (Master branch cloned 31.08.2020).
The workaround worked for me is adding a pause with time.sleep() between retries. Then it works mostly after 2-5 retries.

import time

....

def rename_with_retry(path_from, path_to):
    if sys.platform.startswith('win'):
        retry_count = 100
    else:
        retry_count = 1    
    
    for retry in range(retry_count):
        try:
            os.rename(path_from, path_to)
            return
        except (OSError, WindowsError):       # WindowsError until Python 3.3, then OSError
            if retry == retry_count - 1:
                raise
            warn('Rename {} to {} failed, retrying...'.format(path_from, path_to))                
        time.sleep(1)

[georgik]

Issue detected in v4.2 and master in combination with Kaspersky Antivirus. Probability of failure on cmake is about 30%.
How to simulate failure in idf_tools.py:

• install ESP-IDF, install Kaspersky Antivirus
• open ESP-IDF shell
• delete .espressif/tools/cmake
• run install.bat

In "better" cases you'll get just several warning messages.
In "bad" case the process of idf_tools.py fails.

Probability of failure can be increased to 100% by providing only 1 CPU to VM.

Workaround: Temporarily Disable Kasperky Antivirus protection for the installation