Publishing failure in Web Help

[tigerbaz]

Hi There,

Having troubles publshing my Web Help project to a remote server using the FTP connection protocol. Have had a successful history of working with robo help 7 in this way. However, in the last month or so the publishing function has popped up the following error message:

Publishing has been cancelled.

Failed to create directory: D-Drive.

D-Drive is the specified location in the server directory and my guy in charge of the server has assured me that the D-Drive is alive and well and in place on the server. Any ideas why Robo help would decide to recreate the drive when the existing item is in place?

Happy for any advice.

Cheers,

Barry

.

[RoboColum_n_]

Hi Barry and welcome to the RH community.

Is this an access issue. What happens if you manually try to copy the output files to the D drive?

---

Read the RoboColum(n).

[tigerbaz]

Hi Colum,

Thanks for the response.

Using remote desktop to connect to the server, I was able to successfully copy a file from my machine to the destination folder. Is this what you meant by manually copying the output files or is there another way that I should test?

Regards,

Barry

[RoboColum_n_]

That's it Barry. My theory was that this would fail proving it was a security related issue. As it worked, that is discounted. You mentioned that this used to work in RH7. Has something changed in the RH or server configuration to cause the problem? Are you using RH7 still or have you upgraded to RH8?

---

Read the RoboColum(n).

[tigerbaz]

Hi Colum,

Have been using Robohelp 7 consistently with no changes at my end for a couple of years with no troubles of this sort experienced. Have downloaded the trial version of R8 recently in the hope that this would fix the problem bu no luck. Any idea of the sorts of changes (my end or the server end) that could lead to this difficulty?

Cheers,

Barry

[tigerbaz]

Hi Colum,

Further info from my server guy re the problem experienced.

Here's the additional information from the FTP logs on the target server:

The target directory is a Virtual Directory on the server.  What we see from

the RH8 session is:

02:19:00 192.168.3.112 [16]USER Administrator 331 0

02:19:00 192.168.3.112 [16]PASS - 230 0

02:19:00 192.168.3.112 [16]CWD / 250 0

02:19:00 192.168.3.112 [16]MKD D-Drive 550 5

Now, "D-Drive" is a virtual directory, but RH is not even trying to find out

whether the directory exists.  If it was trying to find out if the target

existed it would do one of two things:

Attempt to CWD into the directory "D-Drive" OR do a directory listing of the

"/" directory.  In the first case the CWD would work; in the second case

(because it is a virtual directory) IIS would not return the "D-Drive" as

part of the directory listing as it only returns the physical files and

directories.

What I would have expected from RH would be that it would TRY to access the

directory first instead of trying to create it and expect to receive an

error if the directory did not exist, eg:

02:19:00 192.168.3.112 [16]USER Administrator 331 0

02:19:00 192.168.3.112 [16]PASS - 230 0

02:19:00 192.168.3.112 [16]CWD / 250 0

02:19:01 192.168.3.112 [16]CWD /D-Drive 250 0   -- If this command returned

an error I would then expect RH8 to then attempt to create the directory

What's happening is that the programming is relying on

an error condition in creation of the directory to then decide what to do

next.  At least that's what I think is happening based on the evidence from

above.

Hope this clarifies things somewhat.

Regards,

Barry

[RoboColum_n_]

I am afraid I am unfamiliar with publishing to virtual drives via FTP. All I can add is that if it has worked in the past, the problem can not be with RH7. It must be something that has changed on the server.

---

Read the RoboColum(n).

[tigerbaz]

Hi Colum,

So we appear to have an impasse. If there are settings in RH 7 or 8 that can affect the publishing function, where would I look for these?

Regards,

Barry

[RoboColum_n_]

The only settings are those in the single source layout properties. However if it used to work and nothing has changed inside your RH projects, the problem must be related to the virtual drive. Could you go back and ask your server administrator again to confirm that nothing has changed their end.

---

Read the RoboColum(n).

[tigerbaz]

Still no luck here.....

My server guy has advised that our operations on the server have not fundamentally changed for some time (years). I have read 1 or 2 other posts around this subject and it appears that RH has had similar problems in the past with publishing to virtual directories. All are unresolved though from what I have seen thus far.

Are there others in the community who have a) fixed this problem; or b) come up with a workaround?

[MergeThis]

Is there a particular techno/business reason for using the FTP Connection Protocol instead of the File System option?

Granted, we're not publishing to a virtual server, simply one on our network, so it might not be a similar circumstance. However, a test wouldn't take long.

Actually, it just occurred to me that another way would be to create a new WebHelp layout with the FTP protocol selected (sometimes a layout can get corrupted, and a new one has no problems). Don't copy the old one and rename it; create an entirely new one from scratch! If that doesn't work, try the File System protocol, as first advised.

Good luck,

Leon

[tigerbaz]

Hi Leon,

Thanks for the response. No particular reason for the use of FTP that I am aware of. Simply, this is the method that I know. Have had a quick look at the File system option but I am not familiar with the process so I was not able to make it work. is there a "how to" guide available somewhere on this?

Barry

[MergeThis]

There's no "process" involved. Simply select the radio button for File System in the Publishing page of the Generate wizard, and let RH push the output across your network to the target.

Test it first by sending it to an entirely new location, and verify that it works OK.

Good luck,

Leon

[tigerbaz]

Hi Leon,

Thanks for the response. My previous post about a process for this was based on my relatively limited knowledge of the nuances of networking. If I select the File System radio button, I am then prompted to enter a destination path and this is the grissly bit. How do I find the remote server? My normal process would be to connect to the VPN via the "Connect To" function in windows vista and then to choose the FTP button to publish. But the RH box seems to require a specific network address which I am not sure how to get and the connection parameters appear to be different?

Any clues that you can offer?

Regards,

Barry

[Captiv8r]

Hi there

Normally if you use the File System option you will need to have a mapped drive letter such as G: or some such.

It may work with a UNC address but I'm not sure. (UNC addresses begin like this: \\Server\Folder)

You may also wish to investigate to see if you have a hidden system file named thumbs.db present. This pesky little file is created by Windows when you view the folder using the Thumbnails option and it can wreak havoc with the publishing process until you delete it.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[tigerbaz]

Hi Rick,

Thanks for the info.

I located the Thumbs.db files (4 of these) and deleted them then restarted RH and had another go at publishing - no luck.

Also, my network guy has advised that the File system option will not work because I am technically not networked to the server so I am unable to map the drive that will allow for the transfer to occur.

Is copy an paste of the project files then my only option here?

Regards,

Barry

[MergeThis]

Looks like the tried-and-true copy/paste process is your only way out, since your "network guy" or someone else in IT, broke the FTP environment and will neither acknowledge it or fix it. As to network drives, having previously contracted for several years, I can state that I've never been in an environment that prevented the mapping of network drives (at least two dozen businesses, some at multiple sites).

Good luck,

Leon

[Amebr]

Hi Leon,

It might not be a "true" network drive, but rather a production webserver. In our company we can't map to these - possibly for security reasons rather than technical reasons, I'm not sure. It might be a similar situation in this case.

Amebr

[tigerbaz]

Hi Amebr,

Not that I am a guru in this area but I think the reasons for the non-mapping to the drive are genuine. The guy who manages the servers and the networking in our company is usually very good to deal with and if I can point him in the direction of the "fly in the ointment" he will fix I am sure. Our challenge at the moment is that none of us (in our company or on the forum) seems to know what the right settings need to be.

Might need to go with copy and paste for the time being.

Cheers,

Barry

[Amebr]

For some reason I didn't see your post containing the network guy's explanation. So I was basically saying the same thing, just that I've never bothered to confirm if the reason was technical or procedural.

This may not have any bearing as it isn't related to FTP, but I think it is related to virtual drives...

We have a directory on the network that we generate to and for some reason it decided that if anyone was viewing any file in that location, it wasn't possible to update the project. At that point we tried generating to a separate directory, then publishing to the original location, on the assumption that maybe that would allow the files to be updated correctly. This wasn't the case unfortunately. We now use a work-around where we generate to one location, email the techs to kick off anyone looking at that location (or sub folders) then manually copy the project across.

1. Generate to "staging area".

2. Techs view use some tool to view all users in that folder and subfolders, and forcibly disconnect them. I believe this is a standard Windows tool, but am not sure of the details.

3. Copy and paste the "staging area" to the "live area".

I've been told that this is a "feature" of the technology used and cannot be changed. I think it's a whole bunch of disks that "pretend" to be a set of mapped drives. No explanation was offered for why it worked in that configuration for awhile, then broke, and I eventually gave up trying to find out.

We were confused for a long time because sometimes it would work and sometimes not. We came to the conclusion that sometimes people weren't viewing it when we did the release and sometimes they were and obviously we (the writers) don't have any visibility on that and the error message just said it couldn't be generated, not that someone was viewing a file.

It couldn't hurt to check with your tech to see if this is a possibility, given that no other suggestions have worked (although booting your users off the webserver isn't ideal).

[tigerbaz]

Hi Amebr,

Thanks for the response.

Will give your suggestion a go and see if this makes a difference. The explanation offered here may go some of the way to clarifying that slightly mystifying aspect of this which is just as you say - it used to work fine but not anymore with no changes made.

Cheers,

Barry

[Peter Grainge]

I am wondering if the virtual directory thing is a bit of a red herring. See Snippet 55 on my site. Publishing Cancelled is a known problem but fortunately it only occurs occasionally. Usually trashing the folder and recreating it fixes the problem.

It should not be necessary to only publish when no one is viewing the site. If that were true, I would never be able to update my site! I believe the theory is the browser caches a copy for the visitor to view and the original can be updated at any time.

---

See www.grainge.org for RoboHelp and Authoring tips