The fully qualified file name must be less than... error

[lisab]

Hello - I have been getting the pesky "fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters' error with a specific project when I attempt to generate HTML help. It has several companion projects of comparable size and file name/path length that compile perfectly. I've tried copying the project to the root directory in an attempt to shorten things up (I read a recent post in which this was recommended). No luck. I looked on the Web and see that it can be a caching problem. Any help is appreciated!

[LTinker68]

Make sure that the output location specified in the target is either set to default or set to a location with a shorter path. Just copying the project to the root won't change the path of the output file if you had something other than the default specified.

[lisab]

I've always used the default, and I just specified a desktop folder as the target. Again the publish failed. I've tried removing topics from the TOC to see if I can isolate a particular file that might be troublesome, and I'll continue that on Tuesday. But other ideas are greatly appreciated!

[LTinker68]

Is this a project created in Flare or is it an imported project?

Do you have the same problem if you create a new project from scratch and try to build it?

[RamonS]

A desktop folder is also buried deep in the horrible My Documents and Settings directory structure. Copy your project to a directory called "work" straight in the root of your C: drive and then try again. If that still fails shorten the folder name to a single letter. If that still doesn't work, you need to shorten names in the project or flatten the structure. And send your bill for the time wasted to Microsoft.

[owilkes]

Hi,

I've had this problem countless times (a result of migrating from a wiki, where it wasn't an issue and people got carried away).

1. Get a full directory listing, including all the subfolders - launch CMD, navigate to your Content folder, and run:

dir /on /b /s > list.txt

Open this up in Excel - the contents should all be in Column A

In Column B enter :

=LEN(A1)

This gives you a count of the number of characters from Column A - however, it also includes the name of the topic as well.

To extract this, enter the below into Column C :

=REPLACE(A1,1,LOOKUP(2^15,FIND("\",A1,ROW(INDIRECT("1:"&LEN(A1))))),"")

To list the length of the topic name, then in Column D enter :

=LEN(C1)

Then - to get the file path on its own, in column E enter

=B1-D1

You can then fill down columns B-E, and sort to get the longest named topics/named file paths.

Hope this helps.

[RamonS]

Thanks for the tip, but the limitation of actually 255 characters is a restriction of DOS that still exists even in Windows 8 (*nix bases systems never had that problem!). And that includes path, file name, and any parameters and switches.
Still, splitting it up in path and file name will show if the path is just long or if someone got carried away with the file name. As mentioned now several times: if on Windows, the shorter the better.

[i-tietz]

HTML Help is compiled with a very old software (HTML Help Workshop) - that's why the 256-characters-limit is still relevant.

If you cannot switch to another format, you should rename the folders and maybe even the file names - if your computer is not too fast for Flare, that is ... OUR computers are too fast and the necessary link update doesn't work properly anymore so we try to avoid renaming and moving objects.

[Paul Griffiths]

... if your computer is not too fast for Flare ...

WTF?

Please tell us more!

[i-tietz]

The first thing we noticed was that the content of the preview window wouldn't react to being resized - the window could be resized, but the content, i.e. the line breaks stayed exactly the way they were before: Enlarging the window generated an empty frame around the visible content, reducing hte size made content vanish without the scrollbars adapting.

In the meantime I noticed that on moving files to another location in the project, Flare is sometimes unable to perform a full link update. The more links there were to and from the file, the higher the percentage of links not updated correctly. So after moving such a "relay" file I got a few broken links, because Flare wasn't able to update them.
And I suspect that our problems with our source control, i.e. with the merge tool and with wrong status messages have to do with that, too - but that's just a suspicion - we have no proof so far. On the other hand: How should we prove something like that?

To be fair I have to say: We didn't only update to quicker computers, but also to Windows 7 (from XP) and to Flare 7.2 ... so I cannot REALLY definitely say what is the cause for all those oddities - maybe we never will.

[i-tietz]

See here for what it looks like: http://forums.madcapsoftware.com/viewto ... =9&t=13479

[RamonS]

HTML Help is compiled with a very old software (HTML Help Workshop) - that's why the 256-characters-limit is still relevant.

That is not the reason. Windows has this limitation and you run into it with ANY Windows application, regardless how old or how new it is. Create a simple batch file and bury it in folders that each have names of 200 characters. Then go to the root and try to execute the batch file. You will get an error. This is solely based on Windows, even the Windows 8 preview, clinging to DOS 'technology'. It is a file system limitation that was included into NTFS, which itself is a relic from the stone age. That is why plenty of people want Microsoft to either create a new file system or use one of the many good ones already available. And yes, Microsoft should also establish a new help file standard, but that would require Microsoft to start caring about users. They rather spend time and effort on sabotaging everyone with ribbonized UIs.

[NorthEast]

See here for what it looks like: http://forums.madcapsoftware.com/viewto ... =9&t=13479

Tip: For the re-sizing issue in the preview, just press F5 to refresh the page.

[i-tietz]

Doesn't work. Only< closing the window and opening it again works.

[NorthEast]

Doesn't work. Only< closing the window and opening it again works.

Strange, works fine for me; pressing F5 refreshes and updates the preview after a resize (Vista 64 / IE9).

[i-tietz]

As I said: Our computers are too fast for it. MC Support told me that they don't have a computer that fast in the house - they can reproduce it on a computer which is almost as fast as our's.
The whole of our documentation department faces that issue cos' everybody here has the same sort of computer ... (thanks to a colleague and me - we are working on a project that REALLY needs a heck of a lot of resources to come up with a performance that doesn't make us fall asleep after each mouse click)

[RamonS]

There is always CPUKiller if a system is too fast. I used it with great success, but more for taking screen shots of status messages that otherwise would show up and be gone faster than I could capture them. See http://www.cpukiller.com/...unfortunately, it is not for free, but it does a great job. There is also Mo'Slo (http://www.hpaa.com/moslo/), which is a few bucks cheaper.
Alternatively, you could enter the system's BIOS and manually underclock the processor and disable the cache.

[i-tietz]

mmmhh ... thanx ...
That might be a good thing if we're not working on that specific project ... but when we do ...
We usually have the application open when we write the topics in Flare ... and I wouldn't want to deliberately slow down that application ...

[RamonS]

CPUKiller has a button with which you can turn the crippling on or off. So you can turn to turtle mode only when needed.