Catapult log when publishing

[LTinker68]

Has anyone figured out how to get the catapult.log.zip file from being created when you use the Publish feature in Flare? It's created regardless of whether or not I view the log file after publishing. I don't want or need that file and it's annoying to have to delete it every time. So... Anyone figured out how to prevent it from being created?

[NorthEast]

The catapult.log.zip file isn't the (upload) log file that you view; that's stored inside the output temporary folder.

I'm pretty sure it's related to the Remove Stale Files option; because if you publish the same target twice then normally nothing is uploaded the second time, but if you delete the zip then it will upload everything again.

I don't know how to stop it being created though.

[Andrew]

I'm pretty sure it's related to the Remove Stale Files option; because if you publish the same target twice then normally nothing is uploaded the second time, but if you delete the zip then it will upload everything again.

Yep, I'm pretty sure that's correct, but I think it is created regardless of if you select that option (though you may want to test to be certain...I haven't look at it in a long time).

[LTinker68]

Yeah, I can confirm it's created (and worse, published to the destination) regardless if the stale files option is enabled or disabled.

I submitted a feature request asking that the file either not be created, or if it is, not to upload it to the destination.

[Andrew]

Not much point to it if it isn't uploaded to the location.

[LTinker68]

Why does it have to be uploaded? Especially if it's a ZIP file? How could Flare be using that? The project folder has a FileSyncCache folder -- seems like that should be enough.

How this really caught my eye is that I created a publish destination for my PDF output that puts it in the Resources folder of the project because the PDF file is provided through the online output as a resource users can download and/or view. The publishing option was faster than me manually copying the PDF file from the generated output folder and pasting it into the Resources folder then building and publishing the online output. It's just annoying to have to remember to delete the ZIP file.

[Andrew]

Why does it have to be uploaded? Especially if it's a ZIP file? How could Flare be using that? The project folder has a FileSyncCache folder -- seems like that should be enough.

My guess would be that users don't necessarily publish from the same computer every time, nor do users necessarily publish to the same publish location every time, so it's important to establish which files actually exist in the particular publish destination. There are certainly other ways to do the same thing, but I wasn't trying to establish a best practice, merely note why I suspect the current functionality works the way it does.

I agree with you that it should have been implemented more cleanly.

[samjones6]

Why does it have to be uploaded? Especially if it's a ZIP file? How could Flare be using that?

I agree.

The presence of the zip file is just messy. It does not belong there. It is part of the build / publish log, not the output...

[RamonS]

Why does it have to be uploaded? Especially if it's a ZIP file? How could Flare be using that?

I agree.

The presence of the zip file is just messy. It does not belong there. It is part of the build / publish log, not the output...

The file keeps track of what was uploaded when so that Flare can figure out which files changed. If that file is kept on the local machine and build/ publishing is done from a different machine the whole feature wouldn't work. My assumption is that Flare first downloads the ZIP archive and the processes the content to build a list of files that need to be uploaded. In that case compressing the file makes perfect sense as it reduces download time by quite a bit.
Since Flare instances do not share something like a database or network storage where such a file could be placed I can think of only one other place, which would be the project file. For a single user this would be much better (because it is faster and less cluttery), but in a multiuser environment that won't work out, because there are multiple instances of the project file.
If I'd have to design such a feature I'd do it the same way.

[LTinker68]

I guess it seems more logical the way Dreamweaver and other apps do it. They look at the file on the server (or wherever the destination is) to determine if it's older or newer than the one I'm telling it to put (transfer). Plus, if someone does delete the catapult folder, then Flare has lost the mechanism to determine the state of the files, so it'll upload everything anyway.

If the zip file is the way they choose to do it, though, then at the very least, disabling the stale files option should prevent that file from being generated and uploaded. If you don't care if there are stale files at the destination then what's the point of creating the file and uploading it?

[RamonS]

I agree that the file should not be uploaded when the feature is disabled. As far as date/time stamps are concerned, they are notoriously unreliable for stuff like this and I wonder if / how accurately they come over. Just think about the server being located in a different time zone. You changed the file at 10:30 AM, but the file was created on the server at 11:00 AM (local time of the server). How is Flare supposed to know? It could assuming that the GMT bias is set correctly and can be obtained via FTP (maybe it is in some header?). There are other reasons why the file datetime could be different and be useless in regards to determining stale or not stale / changed or not change. You say that Dreamweaver can do that reliably by other means? Any idea how exactly?
So if stale files are to be ignored and Flare is supposed to always upload everything regardless if the file changed or not (more interesting for image and external files rather than the small topic files), then yes, the file is not needed and should not be there.

[Andrew]

The file is in the KB range, and I don't believe it gets downloaded with the WebHelp -- it just sits on the server. I don't really see any problem with it for WebHelp. Yes, Flare could look at the timestamps on the server files, but I don't really think it needs to.

For print or CHM, it makes no sense.

[hoss]

+1 on this issue.
I really need a way to disable the creation of these files.

It defeats a lot of the advantage of the automated publishing with a single click, by having to go around to multiple locations and delete this file.
(I have 10 projects, each with 4/5 conditional outputs, each with 2/3 publish destinations = 100+ places to delete this file!!)

I will also raise a feature request to add pressure.

[RamonS]

The point of this file is that it stays in place. Unless someone explicitly browses to that file it is 'invisible'.

[crdmerge]

Lisa, FAR http://helpware.net/FAR/help/hh_start.htm has a Delete Selected Files option in the Commands menu. If you create a File List that includes that filename with every directory path, you simply open the file list and issue the command. The one-click process should be lightning fast.


Good luck,
Leon

[hoss]

Hi Thanks for the suggestion Leon, but i dont think that helps me.
I'm not publishing webhelp to a server, but rather use the publish fucntion to upload .pdf and .chm files to our company sharepoint folders.
In those locations the extra catapult.zip is very obvious & unwanted.

[hoss]

The point of this file is that it stays in place. Unless someone explicitly browses to that file it is 'invisible'.

But its not invisible!
As mentioned above in my case it's very visible in our company Sharepoint folders.
For those of us that dont need this feature, we should be able to disable it, and the creation of this file in the output.
I have also raised a feature request on this issue (and a bug report for the very slow process that checks this file)

[mshaieb]

As an outsider who doesn't use the tool but rather uses the published output to include in installation packages, I really find it hard that developers find it acceptable to add such file (catapult.log.zip) to the published folder. A file which has nothing to do with what we want to publish.

What is worse, so many people appear to complain about it but still MadCap don't appear to get the point.

It is madness! get rid of it please?

[RamonS]

There is a point to that file and that's why it is there. The best solution would be to make it optional. That also means that Flare publishes the output to the designated location and does nothing else, such as cleaning up stale files or updating only those files that indeed did change. I think it is not ignorance or arrogance of MadCap developers when they implement a feature that is useful and is probably used successfully by quite a few. Only because some Flare users have no use for that file doesn't mean that everyone else has no use for it either.

[LTinker68]

There is a point to that file and that's why it is there. The best solution would be to make it optional... Only because some Flare users have no use for that file doesn't mean that everyone else has no use for it either.

I agree with RamonS. The file is useless for my PDF output that I publish back to the project for inclusion in WebHelp or HTML5 outputs, but the file is useful for the WebHelp/HTML5 outputs themselves, since it does track new/deleted/modified files. Although I just opened the zip in an output and it was empty, so I'm not quite sure how the file actually works. Windows blocked me from extracting the file in order to protect the computer, so perhaps there is something in there that you just don't see when you double-click into the zip file.

[mshaieb]

I have only ever seen empty catapult.log.zip files in our published documentation. The documentation team have a batch file that attempts to delete the files but that process often fails.

I can see your point that the file may be useful but from my point of view, it is not right to provide a publish mechanism that creates extra files on the output.

Anyway, I have now added a line of code to my build scripts to delete catapult.log.zip.

Thank you for the replies and apologies if my earlier comment was a bit unsympathetic.

[i-tietz]

It's empty in Windows, yes. But I opened it with 7zip and found an ASCII file with this content:

Code: Select all

<fl>
  <f p="default.chm" c="E1CDFF57914B6E8EE2F851D03D908F68333D84D9" />
</fl>

Whatever that means ...

[mshaieb]

Yes you are right but even member of our documentation team didn't know that the file is not empty.

I have just shown the content of the file to one of the developers and he was shocked to see his name in the path.
catapult.log.zip\C:\Users\username.surname\AppData\Local\Temp

Users should be able to turn the feature off if they have no use for it.

[LTinker68]

Users should be able to turn the feature off if they have no use for it.

Agreed. At the very least, if you disable the option to remove stale files when you publish, then it should prevent Flare from creating the catapult file. I tried that with the PDF output but I'm pretty sure it still created the file, even though I had "remove stale files" disabled.

Make sure you submit a feature request at https://www.madcapsoftware.com/feedback ... quest.aspx if you haven't already.

[BeccaNicole1478]

I know this issue is from several years ago but did anyone find out how to make it stop? I have several projects that I publish to a shared folder through the whole company and only *one* of them is publishing this zip file. I have checked all of my targets/settings and can't seem to find where the difference between this project and my others is. Please help!