Publish failure: problem with access to file

[mafaulkner]

I'm desperate! Our repeated attempts to publish our target fail for the same reason every time: "Access to the path 'yadda yadda.filename.htm' is denied."

This is just a tiny, unimportant file in the scheme of things, and I can't discern a difference between this file and its folder-mates. The build process works just fine.

Any clues? Did I mention that I'm desperate?

Thanks.

[roboHAL]

I suggest you try copying or moving the files manually. Meaning, instead of using Flares publish feature, use windows explorer. That might help isolate the cause. It could be that the file in question resides in a folder that you do not have permission to write to, the file is read only, the file is in use by someone else, etc.

[mafaulkner]

We really don't want to move our files manually, but we might have to resort to that.

As I mentioned, there is no apparent difference between this file and others in its folder--the problem isn't a matter of permissions, and it's not checked out.

Thanks anyway!

[mafaulkner]

This is maddening--when we delete the problem file, a different file becomes the problem: with the same message about "access denied." I can only assume that Flare is going to reject every single topic, one at a time.

As noted, we don't receive any error messages with the build process.

[Msquared]

May not be relevant at all, but since you're desperate . . .

. . . and it's not checked out

From this, do I assume that your published target files are under source control too? If so, unless the target file *is* checked out, you won't be able to overwrite it with a newer version. And if you delete the offending target file, that will copy OK, and you will just get the same problem with the next file that Flare tries to copy.

As I said, may not be relevant, but fits the facts as I understand them from your description.

[mafaulkner]

I'm not sure I follow you, Marjorie.

Yes, our target file is also in source control, but as with all the other files, we check it out before changing it, and then check it back in. How does this relate to the publishing problem? Why would building work and publishing fail?

We contacted MadCap Support with this issue and they were absolutely no help at all. In fact, of the three problems we've contacted Support about, they have actually helped with exactly zero.

But that's a different issue!

[Msquared]

Why would building work and publishing fail?

Bear with me, as I don't know your exact environment, so I may be completely wrong . . .

When you build, you need to create the output files in whatever location you have specified for the build output. When you publish, you need to copy those files from the build location to the publish location.

Now, if the directory you are trying to create the files in, or copy them into is empty, you should have no problem. But if the files already exist and are read-only, then you will not be able to overwrite these with the new versions, unless you delete the old versions first.

One of the ways that the files may exist and be read-only is if they are under source control and have not been checked out (you mentioned in your original thread that they weren't checked out). If the build is working but the publish is failing, then I just wondered if the published files were also under source control and hadn't been checked out before you tried to publish again to a location where old versions of the files already existed.

If you're still having problems, what happens if you select all the files in the publish folder and make sure that the Read-Only attribute is cleared?

Oh, and when I said "published target files", I didn't mean the Flare .fltar files. I meant the files that were the target (or destination) of the publish command. Sorry for the confusion.

[mafaulkner]

Now I think I follow you, but I don't understand how the published files would also come to be linked to source control. Our process is that I check files out of source control onto my hard drive, edit, and then check them back in. Flare builds to server A, and then theoretically publishes to Server B, from which our IT people grab them and make them public.

Publishing used to work correctly, but now it doesn't work unless we delete all the old files from Server B. Since that's unwieldy, we now use a batch process to copy the changed files from Server A to Server B.

I just checked the properties of a couple of files on Server B, and they are not read-only. However, maybe the batch process makes a difference.

Does Flare normally publish by copying files from server A to Server B, or does Flare build directly to A and publish directly to B? I frankly haven't understood the difference between building and publishing: they seem to be identical processes.

Is there a reason we couldn't just build to Server B and skip publishing completely?

[Msquared]

It wouldn't be normal to put the published files under source control, no, which is why I said my original suggestion was a long shot.

You can build straight to server B if you like, and skip the publish step, provided you have a copy of Flare on server B, but if you don't address the underlying reason why Flare can't seem to create files there, you may find the same problem. Again, this is only a guess, as I don't know what the problem is.

There are lots of reasons why there are two separate steps. In some environments, there may be a review step between build and publish. In others, Flare may only exist on server A, so can only run on server A, so if the final destination is server B, they will have to be copied afterwards. Or the final publish destination may be an FTP location, where you won't be able to build directly.

Have you checked with your IT people? Has something changed about access to server B? Have they upgraded the OS, perhaps, or tightened security? Can a normal domain user on server A copy a file to the publish location on server B, if a file of the same name already exists? What about the user under which the build/publish process is running?

This is so looking like a problem for your IT department, and in that case, there is little Flare can do to report the error, as it is outside Flare's control.

[Glahe]

I'm having the same frustrating problem, and changing the properties on the server (clearing the Read-only option) did not help.

Did you figure out a solution eventually?

[sdcinvan]

I'm having the same frustrating problem, and changing the properties on the server (clearing the Read-only option) did not help.

Did you figure out a solution eventually?

Hello, I don't know the exact nature of your problem but I encountered something similar in my early Flare days. The solution turned out to be as simple as closing File Explorer, which was open on the Flare OUTPUT folder.

[Glahe]

Thanks for the suggestion, @scdinvan. I tried it, but it didn't work for me. I've submitted a support case to MadCap.

[nielsf]

This is a permissions issue.
In your wwwroot folder, right-click the flare folder (or whatever you call your flare output folder).
Choose Properties > Security.
Click the Edit button
Select the "Users (Your Machine\Users)" group
Check the Modify permission for the user group, and click OK > OK.
You should now be able to publish to your localhost.

This (or something like this) should be added to the Flare manual.

-Niels

[ctremblay]

This is a permissions issue.
In your wwwroot folder, right-click the flare folder (or whatever you call your flare output folder).
Choose Properties > Security.
Click the Edit button
Select the "Users (Your Machine\Users)" group
Check the Modify permission for the user group, and click OK > OK.
You should now be able to publish to your localhost.

This (or something like this) should be added to the Flare manual.

-Niels

Thanks so much. This is the problem I was experiencing in my recent upgrade to V11.1. Once I modified the permissions - everything worked just fine. This is a big deal - I waited 4 hours for my build/publish and we were just about to unistall v11.1 and return to v10. Now that I have modified the permissions, it only takes about 5 minutes now (as it should). YOU ARE MY HERO!