IDE fail "...rename 'core\core.a'; reason: File exists" or "reference to main"

Hello and thank you for helping.

I have been using Arduinos for years. Currently using 32U4 as "Leonardo". Windows 10. IDE 1.8.5. Uninstalled, erased directory and re-installed. I have erased all libraries in the Arduino directory.

My problem manifests in two ways:

1) attempting to VERIFY a known good sketch, I get the following error message (32U4 board is not plugged in to USB port or is plugged into USB port - no difference):

c:\programfiles(x86)\arduino\hardware\tools\avr\bin../lib/gcc/avr/4.9.2/../../../../avr/bin/ar.exe: unable to rename 'core\core.a'; reason: File exists

I can sometimes work around this bug by verifying a NEW sketch with empty setup() and loop() statements, but this has started to fail resulting in an error statement ending in something about unresolved reference to main.

Under this condition, if I switch to UNO, it usually verifies, but switching back to Leonardo it does not verify. Killing / reopening the IDE several times (over 10) does not affect the outcome.

I am running McAfee and have tried turning it off, with uncertain results. The intermittent nature of the bug does not allow for certainty. The IDE will be working fine for awhile, then start exhibiting this behavior. Many times, verifying an emptly sketch will allow me to continue working, sometimes it leaves me at wits end. I know this or a similar bug has been reported years ago, but I could not find a resolution.

Any ideas? Thanks again.

Same here : unable to rename 'core\core.a'; reason: File exists tried running as Admin changing folder permissions changing install location of ide....

I have the same problem. Sometimes it says Unable to rename reason: File exists. I've tried reinstalling the IDE and libraries from scratch, but no luck.

Has anyone found an answer?

I am also searching for a fix to this. After upgrading from 1.6.5 I've managed to get a clean compile maybe 5 times but only at the cost of 8 or 9 hours now of multiple uninstall/reinstall cycles, trying different boards and sketches in attempts to isolate the problem, cleaning temp files and registry, switching between Windows installer and portable zip install method, and so on.

  • Thought it was my add-on libraries but it happens with the blink sketch and even a new empty sketch.
  • Thought it was dirty cache but it happens after a clean and restart.
  • Thought it was the board type but it happens with all the boards I've tried.
  • Thought it was the PC but it happens after I reboot.
  • Thought it was the wrong day of the week but it happens every day of the week. (At this point, even superstitions are beginning to seem plausible as root causes)

I'd offer some insight if only I could associate the clean compile events with something specific. I just got one by selecting Uno board before shutting down, restart and compile a new empty sketch, then switching back to NodeMCU 1.0 and compiling the real sketch. Next one cratered. Last clean compile before this one was after a complete uninstall/reinstall. Subsequent uninstall/reinstall didn't fix it.

Googled around and see this issue has popped up several times over the years but none of the fixes I've found works. Any suggestions?

This sort of error could be caused by your antivirus software. Try TEMPORARILY disabling your antivirus for a single compilation to see if the problem goes away, then turn the antivirus back on. If the problem doesn't occur with the antivirus off you will need to adjust the settings of your antivirus to whitelist the appropriate file, folder, or process so it doesn't interfere with compilation.

So far, so good. Thanks!

Incidentally, turning off live scanning makes the compile run a LOT faster. In fact, I can pull up the AV control panel, disable scanning, run the compile, reenable scanning, then close the control panel, and STILL save time over compiling with AV enabled. I knew the AV imposed some latency, but I had no idea just how much. I'm going to contact them to see if they can whitelist using a wildcarded path since the Arduino build directory changes every time it starts.