MadCap Software Forums

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).

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.

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.

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.

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.

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.

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.

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).

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 update.

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

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?

Curlyshell wrote: Mon Oct 28, 2024 9:12 am 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.

Have you found a solution? I have the same issue and it's driving me nuts.

On my old laptop, I was working on the documentation locally with everything synced to my personal drive within the company. I'm the only person using Madcap Flare and in charge of the documentation, so it didn't matter much as long as my projects were synced. I got a new laptop and decided to work directly on the general SharePoint folder instead of locally. So I exported all my projects there, and I'm now encountering the same issue as the one you had. Everything works well except for the preview and build. If I delete the temp folder, I can preview or build once - whether it's pdf or html - but not twice. The temp folder has to be emptied every time. It's really getting on my nerves! I could work locally again, but that's not how it's supposed to be done.

Well I have a general solution, though not necessarily one for creating builds on SharePoint. Here's what I understand to be true:

• OneDrive is locking the files to sync, and not unlocking them.

• If you use OneDrive as your backup, well you sure as heck want OneDrive to continuously sync.

• The only folders that continuously sync are the Big Three document libraries: Documents, Pictures, and Desktop. (You can't just deselect subfolders in one of these libraries.)

• Any other folders you sync with OneDrive will sync on command, but not continuously.

Microsoft gave me a solution, which I haven't yet tried. Right now I'm just pausing sync before I open Flare, and resuming after. If you have previously run a build or preview without pausing, you'll first have to delete your Temporary folder and possibly any target outputs.

Here's Microsoft's messy and incomplete solution:
https://answers.microsoft.com/en-us/mso ... e1fde2a2e6

Send Feedback to Microsoft! Click your OneDrive icon > Settings > Send Feedback.

I store my files in a directory not automatically synced by OneDrive, but used the mklink /j command to make OneDrive back up that folder.
I don't see the problem continuously, but when I do it can either be the Temporary folder under output or the actual output folder for the target that causes the issue. It happens regardless of target output type.

I'm wondering since I'm using a non-standard folder to backup if I can exclude \Analyzer and \Output folders from my backup using the method form the Microsoft link. Besides the file lock error, some files in those folders have odd names that cause issues with my OneDrive backups.

Valiant wrote: Thu Jan 09, 2025 7:19 am I'm wondering since I'm using a non-standard folder to backup if I can exclude \Analyzer and \Output folders from my backup using the method form the Microsoft link. Besides the file lock error, some files in those folders have odd names that cause issues with my OneDrive backups.

Hmm...I wonder if the odd names are causing the entire issue?

Curlyshell wrote: Thu Jan 09, 2025 8:50 am Hmm...I wonder if the odd names are causing the entire issue?

The odd file names cause me an error on the OneDrive side, not the Flare side.
OneDrive doesn't like certain files (name too long, odd characters, whatever?) especially fllnks files in the \DepSets directory within the |Temporary folder. I get a red X in my OneDrive icon in the system tray when this happens. This is a corporate Onedrive, no idea if other versions function the same. If I exclude output from backup I might cure this issue and the Flare issue at one time.