Build failed: Access to the path is denied

[Valiant]

I am regularly getting this error. It started with Flare 2024 and continues with Flare 2024R2.
The path in the error can be the output folder for the Target or the Temporary folder under Output. And it's everything in that folder. I have to manually delete the folders. However, there is no problem deleting them from the Windows explorer interface. There is no warning the files are in use and can't be deleted when deleting from explorer.

I fully expect that this could be a permission issues with something my company does to manage our computers, but it is inconsistent. Sometimes I can build and rebuild with no issues. Other times I am blocked by this error on the output folder, the temporary folder, or both until I delete. It even happens when I haven't viewed the output and happens to both HTML output and PDF output projects (the only two outputs I use).

[BedfordWriter]

It does indeed sound like a permissions issue. Just guessing blindly, but do you ever run Flare with admin privileges? That would create file access problems.

[Valiant]

It just seems odd that Flare would have less permissions than I do as the user on this PC. I don't run it as an admin.

I may try running Flare as an administrator which involves jumping through a whole set of hoops with IT.

[Nick A]

If you are building PDFs, it is usually Acrobat that causes the issue. Its underlying processes hold a PDF open even after you have closed it in Acrobat. To test this (in Windows 10):
1. Close Acrobat.
2. Open Windows Task Manager, select the Performance tab, and click Open Resource Monitor (at the bottom).
3. In Resource Monitor, select the CPU tab.
4. In the Associated Handles area, in the Search Handles box, enter the name of your output file or folder and click the search icon. Don't be too specific with the search term.

This will reveal the process that is still handling the PDF file and therefore causing the 'Access denied' message in Flare. In the case of PDF output, it is nearly always two Adobe processes called AdobeCollabSync.exe and/or AcroCEF.exe.
5. In Task Manager, select the Details tab, right-click these processes and select End task.
6. Go to C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat and rename AdobeCollabSync.exe, for example AdobeCollabSync-STOP.exe.
5. Go to the subfolders AcroCEF (and possibly acrocef_1) and similarly rename AcroCEF.exe.

For many years this has made no difference to the operation of Acrobat, and it allows Flare to (re)build PDF output without interference. If you notice any issues with Acrobat, reinstate those .exe filenames and restart Acrobat. Note that when Acrobat secretly updates itself (even if you have disabled that process too!) it will reinstate the renamed .exe files, so you'll have to rename them again.

[Valiant]

I am familiar with the Adobe problem and work around it by removing the collabsync file, and I've been harassing Adobe to fix that for some time.

But this new problem affects both HTML and PDF output and for the PDF it's not the Adobe process holding the files now. It may affect other outputs but those are the only two I build.
Oddly it is more common first thing in the morning which makes me think it might be somehow related to a night time backup, but it can also happen more randomly in the middle of the day after I've built the targets successfully before.
I suspected viewing the files left something hanging, but that doesn't explain when the temporary output folder is the issue.

[Curlyshell]

This is happening to me frequently but sporadically. The guilty folder is in Output\...\Temporary\HTML5 (or PDF).

Today I could open a page preview one time, but not a second time. This makes me think Flare is opening files and not releasing them when they're closed.

Closing and reopening Flare did not help. But deleting the HTML5 folder did. I could also then open the HTML5 page preview.

Next I viewed the PDF preview, then built the PDF target. Both successful. Until I tried looking at the PDF page preview again, at which point both the preview and the build failed.

And next, I deleted both target folders in Temporary and built the HTML5 target multiple times. Then opened the HTML5 preview. Then built the target again—all successful. Then opened the PDF preview annnnndddd...it broke subsequent builds. But before you go blaming PDF specifically, know that I don't normally output to PDF. This project is copied from something that does have a PDF, so the target exists, but I have never used it before this morning's test. I was definitely getting build failures before I tried viewing/building PDF.

My content folders back up to OneDrive. I don't have any warnings about items in the Output folder not syncing, though there are issues in the Analyzer. Anyone else?

EDIT: I paused syncing in OneDrive but the issue persisted.

[Valiant]

When I had the problem with Adobe collab sync, I could see the Adobe program was holding onto the problem file by using Resource Monitor.
When I use Resource Monitor to see what is holding open the problem files now I get no results.

I'm glad you tried disabling OneDrive backup. I see that was one thing we had in common and wondered if that might be the issue.

I may open a bug with Flare for this because I can't see anything on my system causing the issue.

[zappy0]

Wow - I just posted about this over in the Printed Targets forum on an old thread. viewtopic.php?p=148047#p148047

In my case, OneDrive is the culprit. If I pause syncing I can do multiple builds without the access to path error. However, I had to delete the entire Output folder before pausing the syncing (even when the Output folder had been sync'd).

[Curlyshell]

IMO essential software needs to play nicely with OneDrive.

I won't move my Flare projects out of Documents or opt out of regular backups. That's a recipe for disaster/getting fired.

And this wasn't happening before the latest backup.

I, too, will submit a bug. Dear Readers, please do the same if this affects you. That's the only way to be heard.

[Valiant]

We keep documentation in a folder outside on the Windows documents folder on out PCs.
I used the mklink command to make this separate directory part of my OneDrive backup.
I'm wondering why this appeared out of nowhere? Did OneDrive change something a few months back?