<Errors>
<LogEntry File="../../../Project/Targets/Gateway_SecurityGuide_allOS_en_PDF2.fltar" Message="Build failed: Could not find a part of the path 'D:\SVN\gateway_trunk\en\Output\fvila\Gateway_SecurityGuide_allOS_en_PDF2\index.pdf'.
" LineIndex="-1" CharIndex="-1" Subsystem="Compiler" Target="Gateway_SecurityGuide_allOS_en_PDF2" ErrorID="10086" />
</Errors>
Here are the TOC file and the target
1) TOC FILE ***********************************************************************************************
This happens to me consistently for one particular project. It has very few topics and both target and TOC are very simple. The output is PDF. (If I change the output to HTML, the build is fine. I get this error only for the PDF output.)
Also, if the project is on the local C: drive, the build is OK. The error happens only when we use Flare for a project on a network drive. From your message, i guess your D: drive is a network drive as well.
We can't get a straight answer from MadCap other than "Flare doesn't work well on network drives." I wonder if other users of network drives have the same problem.
I use Flare to modify a project that lives on a network share. The only problem we've ever experienced was overwriting someone else's work. It's a collaborative test/mockup project; our real one is safely contained in source control.
I'm sorry I can't be of more help, but I wanted to address fchan's thought.
Well no, it's not a network drive.
The content is input from Word
I'll try outputting to C: , be back in a second...
Seems to be working for the moment, although the progress bar stops in mid-air for a while.
I'm keeping my fingers crossed...
>>>> NO this has nothing to do with it. I added the cover pages and the build re-crashed !
Things are looking a bit better. Someone advised me to delete the existing output folder and kill any process related to Acrobat reader in the task manager. Seems to work
I did discover that if I do the following, the build is OK:
In the PDF target, go to the Advanced tab and select Glossary proxy.
Whenever the Glossary proxy is selected, the build is successful. Whenever it is de-selected, the build fails with the path error.
This is not a good fix because (1) selecting Glossary would put a glossary at the end of the PDF output, which we don't need, and (2) this works for one particular project but not the others with the same build error.
Again, I don't see the build error as long as the project is on the C: drive. It happens only on the network drive.
What might happen is that overall the path, file name, and command that gets executed to shell is longer than 255 characters. Windows cannot handle this. That is a restriction from DOS that never got removed, not even in Win 10, mainly due to Win 10 still using stone age tech file system NTFS.
None of these fixes are working for me. When I had this problem previously, removing the TOC and adding a new one temporarily fixed the problem, but the issue has returned. It only seems to be for one PDF target for a document I'm trying to produce. Other flare files are working fine so just seems to be this one. I think the build is failing at "creating chapters..." but not positive. Any ideas how to troubleshoot this further? I have drafts due out this week so really need this to give me SOME sort of PDF output
VelocityGirl wrote:None of these fixes are working for me. When I had this problem previously, removing the TOC and adding a new one temporarily fixed the problem, but the issue has returned. It only seems to be for one PDF target for a document I'm trying to produce. Other flare files are working fine so just seems to be this one. I think the build is failing at "creating chapters..." but not positive. Any ideas how to troubleshoot this further? I have drafts due out this week so really need this to give me SOME sort of PDF output
Could you re-create your target for the output in question? I find that if I've changed a target from one type to another (for example if I've made the Help target and just copy that and edit it to create the PDF target) that some settings from the original target type don't get removed.
Just clutching at straws, but that might help. If not, you could try re-creating your TOC from scratch as well.
Using Flare 12.0.599
Flare was failing with this error for both a project's Online help Build and its PDF Help guide build.
None of the solutions below worked, but what did was removing the checkbox in the Source Control section next to:
Automatically get latest version of all files before generating the target.
We just recently moved around our linked subversion folders and suddenly started getting this error. I do successfully poll the subversion link every time I open a project to verify I have the latest project content locally. The issue seems to be only on the Build side.
I have no idea why, but I changed the Output file to default in the PDF target and it fixed this problem. So, PDF target > General > Output File > (default).
For as long as I can remember, Acrobat has had a nasty trick of "holding open" a PDF file, even when you specifically close it within Acrobat, but keep Acrobat open. When another application tries to rewrite the same PDF file, the file system correctly reports that the file is still open. Only closing Acrobat makes it fully close/release recent files it has been displaying, which then lets Flare delete and rebuild the PDF. Long ago, I completed a proper Adobe bug report about this issue, but naturally it was ignored. Only recently (https://forums.adobe.com/thread/2462981) somebody has reported the very same issue, with the obligatory useless advice from Adobe about reinstalling the application. I can only suggest that anybody reading this thread also raises a formal Adobe bug report, and then waits for the billion-dollar sloth to fix Acrobat's flawed file handling procedures.
Moving the project from a network to a local folder (preferably within "C") solves this issue.
Another explanation is that path is > 256 characters, so definitely I had to move the project to "C".
When this issue comes up, and it does often, I noticed it may happen only on one target for PDF. the other five PDF targets have no issues. However, that one target got hung up in Adobe is strange.
My fixes:
1. Delete the Output, if you can - that folder sometimes does not delete.
2. Delete Analyzer.
3. Project > Users - delete the users folder.
4. C:\Users\USER ID\AppData\Roaming\MadCap Software\Flare\ delete CartapultMdiEditor - but be ready for your layout to be gone the next time you open Flare.
And when all of those don't work, there is the need to end the sync process of Adobe. I have gone through all of the above-mentioned. Restarted Flare and my computer, and the build still does work.
Go into the Window Task Manager > Processes tab. Find and Adobe process - AdobeCollabSync.exe. End that process. I have had it happen where I get one build out. But not a second one.
I would like to know if there is a surefire way to ensure Adobe won't keep documents open.
Periodically I have issues with Adobe Acrobat not playing nicely and leaving the AdobeCollabSync process running. This prevents a rebuild of the target from Flare as the output is seen as still open. The process is an Adobe Creative Suite component that makes files available to share between other users. If you're not doing that, the component isn't necessary to either Acrobat or Flare. I found it inside the Program Files (x86)/Adobe/Adobe DC folder and renamed the executable. Now it doesn't run and doesn't get in the way of my build testing.
Anybody out there?
I have this error 10086 every other time I build, so I can build once (on local C:\), everything's fine, but for the next build, Flare cannot find the path anymore. But it has no problems, saving the corresponding .mclog file in the path, it cannot find.
Why is it different, the second time?
What has changed? The path exists and is not empty, ok, but this doesn't stop Flare with other targets in other projects. Why here?
And, yes, the workaround is to delete this specific output directory, but it is a nuisance and a mistery.
I don't know if this will help anyone, but after quite a bit of troubleshooting I discovered that the build fails if the target name is 41 characters or more, excluding the .fltar extension. I don't know if that's the only cause of a build failing because it "could not find a part of a path," but shortening the target name worked for me in several instances.