Can't Publish Project

[Maureen_G1]

Periodically, something within Robohelp appears to get corrupt with a project. When that happens, the project compiles without any problems until you click Publish. At that point, a Webhelp dialog displays, saying "Publishing has been cancelled. Access is denied."

The only thing I've found that fixes the problem is totally trashing the project and starting over. I move the existing project out of its original folder, then import the .hhc file into a new project. It retains the settings and the formatting, and publishes with no problem.

Is this the ONLY solution? Does anyone know how to fix the problem AND keep the project? I'm asking because I have over 20 projects, and they ALL went corrupt today. Usually this problem only affects one project at a time. But today I'm facing an afternoon of recreating them all...

[Maureen_G1]

Oh. And does anyone know what causes this?????

[Peter Grainge]

You do not need to trash the project, just point to a new output folder.

And sorry we don't know why. Folder permissions / Read Only flags have been suggested but I have disproved both.

[Maureen_G1]

Unfortunately, the intranet web site links to the project at a specific folder location, so I'm permanently tied to it and can't change it. I guess I'm doing the only thing I can under the circumstances, eh? At least I know!

Thanks!

[Captiv8r]

Hi Maureen

Perhaps look for the existence of a file on your side of the publishing bit that is named: thumbs.db. Seems I've read somewhere that this little beastie can toss a monkey wrench into the wringer.

Note that you may need to perform the following steps in Windows Explorer to see it.

Click Tools > Folder Options...
Click the View tab
Scroll down and choose "Show hidden files and folders"
DE-select Hide extensions for known file types and Hide protected operating system files (Recommended)
Dismiss the dialog and scan for the file. If you find it, delete it and try publishing again.

Cheers... Rick

[Maureen_G1]

After I posted that, I thought about it and tried to find a way to incorporate what Peter suggested into what I need to do. I renamed the folder "Folder1", then created a new folder with the old folder name (the one the Intranet links to), "Folder". I opened the project from "Folder1" and recompiled with a destination to "Folder". Same problem. (Couldn't compile - you'd think you would though, wouldn't you?)

Rick,
What folder would I look in for thumbs.db? I couldn't find it in the Robohelp Office folder.

[Captiv8r]

Hi Maureen

Assuming it is the culprit, it would have to be inside one of your WebHelp folders that was created during the generation process. I'd look in the WebHelp output folder of the project and conduct a search.

Just an FYI, this is a file Windows creates when you are viewing folders using Explorer and use the Thumbnails view.

Again, I'm not claiming it is *THE* issue, only a possibility.

Cheers... Rick

[Guest]

Rick, thanks so much for the details here.  I've seen this posting before because I've encountered this error, but I must have missed the "Hide protected operating system files" option.  This little bugger seems to have been the problem today.  Found the file and deleted it.  Now I can publish again.  Guess that's what I get for scanning instead of reading thoroughly the first time.  Thanks!!

[Anyhoo]

This is why I just LOVE Adobe Products.  The company seems like it is great and all but usage of their products has left me less than thrilled.  They need to be on top of issues like this and they just never are.

[Jeff_Coatsworth]

not sure why you're chiming in on a post from 2008/2009 about something that Adobe has no control over (i.e. your Windows settings in the location you're trying to publish output to).

​Edited to remove email address

[Anyhoo]

I am on this thread because I am having the same issue with Robohelp in 2016.  Another user said he determined that there was no issue with the target directory being locked and I did the same determination.  So it is an invalid assumption to categorize this as a user error with no responsibility on the software itself. 

[Amebr]

Hi  just want to point out that this is some issue with Windows itself, rather than user error. I sometimes get locked out of publishing and find that closing Windows Explorer can fix the issue. (Note I'm also not saying Adobe is perfect, just that this issue doesn't appear to be something they can do anything about.)

Edited by moderator to remove email address

[Peter Grainge]

Have you tried adding a Publish location that is on your local drive? If it publishes OK there, then it's usually the case that either it is permissions or the above mentioned issue that trashing the output folder and recreating it works. That said, it is now years since I have encountered this myself.

Are you using a recent version of RoboHelp?

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[Anyhoo]

No I have tried adding a publish location on my local drive.  The issue only randomly happens, not always.  It is not something I can easily reproduce. I have noticed that directing the output to another folder first and then directing it back to the folder that had the issue also seems to correct it. I am using RoboHelp 11. I still suspect it is Robohelp itself that is causing this.

[Jeff_Coatsworth]

When you publish, it's basically just FTPing the contents of the generated folder in your \!SSL!\ output folder up to wherever you told it. When it happens again, try using some FTP software to upload it & see if it has an issue. I don't recall if you mentioned where your published location is - is a folder on a web server or someplace internal to your operation? I just wonder if the files are being tied up because of someone accessing them while you are trying to replace them.

[Anyhoo]

The published location is on a network drive on our local intranet. It could be that someone else is accessing the files as I am trying to replace them.  I did not intend to come off sounding so critical of Adobe or Robohelp.  I appreciate the assistance everyone here has provided.

[Anyhoo]

Here is an update about this issue which to me appears significant.  Today I again got this issue multiple times when I was publishing my Help project, so as a workaround I generated help and published to a temporary location on the same network drive where the original help project that is having this issue is located.  Once that was done I copied all the published files from the temporary location to the original location and there were no issues in copying.  If the issue really is locked Windows files as some here are saying, how am I able to copy over those same files in Windows Explorer without issue that RoboHelp repeatedly said it was denied access to? 

[Captiv8r]

Hi there

One possibility is that at the moment you were copying any file that may have been locked before actually had the lock released.

I'm not sure anyone has categorically stated that THE reason this is happening is because files are locked. It's only been mentioned as a possibility.

I find myself wondering if RoboHelp just consistently refused to publish. Also, when the process bombs, is anything posted in the dialog that may mention what the file it gagged on is?

Cheers... Rick

[Peter Grainge]

@anyhoo What you have done in Post 23 in this thread is effectively the same as my original response in Post 2. Trashing all the content by one means or another (your way or mine) is the fix. If only we knew why.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[Anyhoo]

I'm glad I'm not the only one who is having this issue and that others besides me at least suspect it is an issue with Robohelp and not just due to Windows locked file(s) and/or directories.  One thing I have noticed is that the issue does not always happen but when it does it happens consistently from that point on.  In other words, if the Robohelp project is left open and you publish over and over again, you will get the issue over and over again no matter how many times you publish.  That has been my experience at least. 

[Peter Grainge]

If Rick's suggestion is not it, then still no need to trash your source. Trash the target folder and then create a new folder with the same name.

[Maureen_G1]

Peter,

Our postings crossed! The fact that I couldn't reuse the project to publish in a different location suggests the corruption is in the project itself. However, it doesn't carry into a new project when you import the .hhc file. I may have a different problem from the one you've encountered, because so far that's been my only fix!

Thanks!

[Peter Grainge]

Anything is possible. All I can say is that the solution has worked for everyone else. That would also fit with Rick's suggestion as the process would trash those thumbs.db files.

[Maureen_G1]

Peter, you were right. I was confusing "output file" with the "Select Output Folder" field in the project setup - the one that goes to the C:\ drive. I went back in and deleted the output folder on the server and THAT'S what fixed it! All's well again! Thanks much!

[MergeThis]

Going back to your initial posting, in which you state that the project generates fine, but publishing does not ("Publishing has been cancelled. Access is denied.").

You might be overreacting to the identical situation that I encounter from time to time, which apparently is simply caused by excessive traffic on our networks, rather than any project corruption.

As long as you have published the project once (that is, the "Server Name" link has been checked and you have published), then right clicking the WebHelp layout and selecting the Publish option allows you to publish the output that was previously generated without having to re-generate it.


Good luck,
Leon