Compiler Error (Internal) - Path or File Name too long

[scorriher]

Has anyone received the following Compiler Error when bulding Web Help output?

Compiler (Internal Error): The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

I believe my project meets these requirements, and I have compiled this Flare project before!

Any advice would be greatly appreciated.

Thank you.

Susan C.

[RamonS]

Just one character over is enough to send Windows into a tailspin. It is a Windows limitation dating back to the DOS days and the true limit is 255 characters and not 260 (no clue why Flare reports it as that). While the paths within the project may be short enough they may end up to be too long when building the project. The easiest would be to move the entire project folder to something like C:\hlpdev or any other short folder straight off the root of a local drive. The alternative is to hunt down which topic is the problem and shorten the file or path name.

[NorthEast]

Yep, for simplicity, I'd probably just move the whole project as RamonS suggets.

If you can't move the whole project, you can set a different output folder for the target (to something shorter); as it seems to be the path length of the output files that is the problem.

[scorriher]

Hello,

Thank you for the replies.

My technical counterpart actually discovered last night that copying the Flare project to the network and back to my local drive several time has caused a long source project path on the Import tab (Project Properties -- Import -- Source Project tab.

It looked like this ...\...\...\...\...\c:\program files\<remainder of path>

Removing the path to the point of the C: drive fixed the problem.

I wanted to pass this along.

[todd.richardson]

My technical counterpart actually discovered last night that copying the Flare project to the network and back to my local drive several time has caused a long source project path on the Import tab (Project Properties -- Import -- Source Project tab.

Are you using Flare 8? I don't see Project Properties > Import > Source Project.

I encounter this issue when trying to build a Word target for one of our projects. I can build the PDF target of the same source/project fine. Even stranger, I was able to build the same Word target without errors a month ago. The project hasn't moved. The output directory hasn't changed. I'm completely at a loss. Any ideas?

Thanks.

[Msquared]

If you can't move the whole project, you can set a different output folder for the target (to something shorter); as it seems to be the path length of the output files that is the problem.

Be very careful if you set a different output path in the target from the default output path that Flare uses. I did this and I got stung. It's far better to fix it properly by shortening names if you can.

I had a long path because
1. I have my own working folder structure on my PC
2. below that, I have the workspace structure imposed on me by our source control system
3. below that I have the structure of the repository itself, so eventually I get down to my branch of my project and the doc area (as opposed to the code area)
4. Then I have the my own doc structure (Flare vs Word content, shared content, folders for each language variant)
5.then I have my Flare project structure and eventually I get to the \Contents folder
4. below that, I have a couple more folder levels to keep my mass of topics in some sort of order
5 most of my topic names are longish as I've tried to keep the filenames matching the topic titles for ease of locating stuff.
6 if you build a Webhelp Output then you are going to replicate this structure exactly, sight down to the last .htm filename. i just had two or three files that were too long by a character or two.

No problem, I thought. Rather than try to persuade my developers to move my documentation further up the source control structure, I'll just move the output folder higher up my own folder structure and free up a few characters.

But this means that your target now contains an absolute foldername/filename for the output file. At the higher levels this will include your own folder structure on your PC. In order for anyone else to build your project (a colleague, or in my case, the translators) they will have to replicate your folder structure, or the build will fail.

Unless I'm missing something in my inexperience, I'd say don't go there! Keep the output folder exactly where Flare wants to put it. Unless of course, anyone knows differently . . .

[Msquared]

I encounter this issue when trying to build a Word target for one of our projects. I can build the PDF target of the same source/project fine. Even stranger, I was able to build the same Word target without errors a month ago. The project hasn't moved. The output directory hasn't changed. I'm completely at a loss. Any ideas?

I'd guess that the name of the PDF output folder/file is slightly shorter than its Word counterpart. So one is just inside the limit and the other is just outside. Or, perhaps there is some intermediate file that is being created (there is all sorts of temporary stuff saved in your project area) that is now too long. Just guessing, perhaps you have added an image file, say to the project with a name that just tips the limit now when processing. When I investigated mine, I did find that I had a file name that was too long. I was able to look at the list of files that had been processed in the build window to see where the build crashed.

[todd.richardson]

Just guessing, perhaps you have added an image file, say to the project with a name that just tips the limit now when processing.

Thanks for the reply. However, in this case, no new files were added since the project was last built successfully. I've only been updating text content. A month ago, the Word output built successfully. Today, it stops with the filename/path limit error almost immediately. I even moved the project source up a level in our Perforce tree, but the problem persists. I am completely at a loss.

[Msquared]

I'm probably teaching grandmother to suck eggs here (and clutching at straws, to mix my metaphors) , but have you by any chance changed the name or location of your Perforce workspace? The 260 character limit applies to the whole file name, including the complete folder path, which will include whatever you called your Perforce workspace. I'm so close to the 260 character timit, that my Perforce workspaces have two and three character names to reclaim as many characters as I can.

Or have you or anyone else changed the Perforce folder structure and hence made your path names longer? Again, the entire Perforce folder structure will be included in your folder structure.

[aliceten]

You can use Long Path Tool, it works for such issues!

[Msquared]

How will that work from within Flare? This is what the description of this tool says.

Each time you would like to manage files that have a long filename all you need to do is to click the icon and it will instantly direct you to a window that presents all your files. Here you can rename, delete, open and move your files instantly without the worries of error messages saying that there is some sort of a problem

How can this stop Flare from reporting (Windows) errors when it generates a filename that is too long as part of a build? Have I misunderstood?

[RamonS]

You have not misunderstood. The "Long Path Tool" is junkware and I wouldn't be surprised if it came with a set of viruses as well. The pointless recommendations for using this tool pop up often in this forum and typically can be removed without any trace. Since this one slipped through, collected responses, and does not contain a link I leave it in place. Fact is, no tool in the world can overcome the Windows limitations that stem from the DOS days. If the entire path is longer than 255 characters you cannot access it directly. And yes, this tool would be utterly useless in the context of Flare.

[Msquared]

I just didn't want anyone to waste time on a pointless recommendation before someone jumped on the post. I didn't realise it was recommending junkware, but I suppose I should have guessed.

[ccardimon]

Just got this message today. Of course it involves a hot potato project.

[ccardimon]

Further info on my experience with this glitch.

I am able to output the files that are throwing the error in PDF format as a standalone document.

But when I insert the files into the larger project as an appendix and try to output in PDF format, then I get the error.

I can output the files on their own as a standalone, but not as part of a larger project.

[Msquared]

That's probably because when you put the files in a larger project, you are nested more deeply, and somewhere along the line, Windows refuses to create a file as the name is too long. This may not be one of the final output files. It may be one of the intermediate files Flare creates. It's a Windows problem, not a Flare one.

Try telling Flare to use an output folder somewhere higher up the tree, rather than below /Output. (There's an option for that, on the project settings perhaps, or the target. I can't remember off the top of my head). Or try mapping part of your file path to a "drive" using a spare drive letter. Then work in that mapped drive - you will have shorter filenames.

[ccardimon]

Got it fixed. On to the next problem.