Build failed: Access to the path: C:\My Projects...denied.

[vmersy]

I am suddenly getting this error when I try to build one of the PDF files. The first time I build it, there is no error. The second time I build it, I receive the error. If I go to the Output Folder and try to delete a folder there, I get the message, "You require permission from the computer's administrator to make changes to this folder." I am the only one who uses MapCap Flare in our company and this was never an issue for me before. I asked the company IT administrator to log into my computer, and he was unable to make changes or build the file as well. I am using version 12. Could it be related to the anti-virus software our company uses? Any ideas you may have about what may be causing this is appreciated.

[devjoe]

Usually this is because you have the last build of the PDF open somewhere. If you opened in in a browser, you may have to completely close the browser before it releases its hold on the file.

[vmersy]

Thanks for your suggestion. I checked to make sure the PDF was closed, tried it again, but am still getting the error. I am able to build the PDF if I use the Clean Project option on the Project ribbon and then reboot. This clears out the folder that stores my PDFs. I have 17 PDFs for my project, which all disappear when I use this process. Then it allows me to build any them once. Twice - and it gives me the error. So I'm hoping to be able to fix the problem with a more permanent solution. I appreciate any ideas.

[trent the thief]

I've had issues with Flare not believing the PDF was actually closed until I closed Acrobat, not just dismissed the file. A couple of times even having an Explorer open that was used to look in to the put put directory kept it from working. I tend to think that this is a windows issue.

[RamonS]

I had those issues with Outlook. After attaching a PDF to an email and sending it Outlook still kept a lock on the file. Restarting Outlook was the only option.

[SteveS]

Outlook and Adobe do not play well together. Snagit can lock files, even after they are closed in Snagit, as well.

If you're having issues you can click the show hidden icons button on the Windows task bar, right click program icons, and close them. The Windows task manager can also be used to force a program running in the background to close.

[zappy0]

I have been having a similar issue the past month so I figured I would revive this old topic to see if anyone has some suggested solutions.

I can work around this by deleting the entire /Output/ directory before each build. But, I can never have two successful builds in a row.

The error I get is "Build failed: Access to the path 'C:\Users\myname\OneDrive - Company\Documents\prod_documentation\project\Rev H 6.10.2\Output\myname\Temporary\Company_PDF\Company_PDF_1EBCA1E5\Resources\Stylesheets' is denied."

If I manually delete the ../Stylesheets/ folder, I get the error but with a different folder name. If I delete the Temporary folder, I get the error but it moves to the main output folder for this project. I get this error whether generating PDF or HTML output.

If I view the Security properties on the /Output/ directory, my account has full control, the Admin account has full control, and if I add all permissions for Everyone, I still get the error.

Windows 11, Flare 2024 r2 installed by the Admin, OneDrive is running, PC is managed by the organization.

[zappy0]

It seems OneDrive is the culprit. If I pause the OneDrive sync and then delete the Output folder, I can do repeated builds without an error. Even if I wait until OneDrive has sync'd the Output folder, it still blocks subsequent builds. Thus, pausing the sync after deleting the output folder appears to be the only way to get multiple builds. Is there a solution for this? I really do not like the idea of pausing OneDrive.

[Jugge]

I had this problem with OneDrive and I found a solution that worked for me. Instead of pausing OneDrive for all files I just turned of the sync for Flares Output folder. This doesn't do any harm since I don't even use that folder. Doing this solved the build problem I had.

1. Open OneDrive Settings
2. Click Account
3. Click Choose folders
4. Locate you Flare Output file and untick the checkbox.

[AlexFox]

There is a File Locksmith utility in the wonderful Microsoft Powertoys that will tell you what process is currently locking a file.

[Curlyshell]

I had this problem with OneDrive and I found a solution that worked for me. Instead of pausing OneDrive for all files I just turned of the sync for Flares Output folder. This doesn't do any harm since I don't even use that folder. Doing this solved the build problem I had.

1. Open OneDrive Settings
2. Click Account
3. Click Choose folders
4. Locate you Flare Output file and untick the checkbox.

Please help resolve my Catch-22. When my Flare folders are in Documents, I can't turn off sync for any folders. When I had them in a C: folder once upon a time, they didn't continually sync. They only synced when I prompted. There was a computer issue and I lost weeks of work! So where do you put your Flare folders?

[Psider]

If your organisation has source control, see if you can use that. That way every time you commit/check-in, your work is saved centrally so it doesn't matter where the projects are located. The reason I only recommend using source control if your organisation already has it, is so you can have experienced people managing the setup of the source control environment. Becoming a source control admin/troubleshooter is not easy. Obviously you can choose to use source control without existing support, just be aware of the learning curve.

However, if your organisation doesn't have source control, I would recommend you zip your projects at the end of each day and copy the zip to a network location as a backup. Make sure you work out a clean up schedule to delete old backups as well - the storage can get out of hand. There's no set rule for when to delete as it will depend on a lot of factors including size of project, frequency of backups, size of organisation and organisation retention policies.

I would also recommend defining a naming convention for daily backups as well as minor and major versions (if you have this complexity in your release process), as this can help determine how much to keep. e.g. perhaps you might decided to keep the last six major release version zips, plus all daily backups for the last 3 major versions. Or, keep the last 5 major version zips, all minor version zips for the last 2 major versions and all daily backups for the current major version. The possibilities are basically endless. :p