A couple of times today I have received a mesage "Could not remove backup file filename~.htm" when I tried to save/close a topic.
This is worrying me.
I could see the backup files still existed in the RH project so I deleted them via Windows (scary).
Should I have done that? Will it now explode?
And why did it do it in the first place? I have been thrashing my machine rather a lot today with numerous apps open.
(Using RH 7)
I'm on Vista as an administrator.
No nothing has changed at all.
If there's nothing obvious then I won't worry about it as it still seems to compile OK.
I just like to understand WHY it comes up with stuff like this as I know seemingly innocuous things can have repercussions later on!
Would this backup files be called something like rtl022.htm? If so, these are temporary files created when you preview a topic. They should be deleted automatically but can remain behind. You say you've been thrashing your PC a bit today. Did you try restarting the PC and see if that fixed the issue?
No, the backup files are copies of the original file. eg if I have a file named 'hello.htm' the backup file would appear as 'hello~.htm'
It looks like it's something that should have got deleted - which is why I helped it on its way.
I did restart but it's an intermittent thing so I can't tell if it's fixed.
I have the same issue, no changes to anything on the OS - RH9 been working just fine for ages, in my recent project though I have been receiving this message every time I save. It appears that topics that I have renamed have been renamed in the RH but not in the system file, EG: New_Topic2.htm has been renamed in RH however this hasn't updated the htm file in the projects folder on my c:/ drive. If i delete New_Topic2 the the topic is deleted from the project. Any suggestions?
I've seen this sort of stuff appear when you use find and replace tools that create a backup when they change a file. I've never seen or heard of anything in Rh doing this, other than in this thread.
Is there some sort of backup utility running in your environment?
You say it's every time you save. Save any change or just a file rename done through Rh?
See www.grainge.org for RoboHelp and Authoring tips
We have Trend running on our network and my pc is monitored for failure and backed up daily by Kaseya.
This was happening every time I saved. I have since renamed the actual .htm files (In the 'My Robohelp Projects' folder on my c:/ drive) to reflect the same name as the topic and I have not received this message again.
To test this theory I created a new topic without naming it (leaving it a 'New Topic 3'), when I renamed the topic in Robohelp the .htm file did not update to reflect the change and I received this message again. A shutdown / restart has not fixed this. Again as it was a test I change the name on the .htm file to reflect the new topic name and the message ceased.
I've deleted my test topic now and I'm satisfied that this is all that is causing the error message however doesn't give any explanation as to why it was working fine renaming topics previously and then all of a sudden it's not. Nothing has changed on my pc or our network. I am the only user on the network with RH and therefore the only user able to access and change any RH documents.
FYI - best practices dictate that you keep your projects in c:\projects\[project_name]\ to keep path lengths nice & short. Don't use the "My RH Projects" folder because it is often strung out on a really long path length.
Could possibly be ShadowProtect too - taking incremental snapshots..? I've started receiving this message again this morning - all topics & files are fine and matching so can't possibly be this any more so it must be something running on our network. To enable our network administrator to investigate properly I need an understanding of what RH is trying to do when it says 'could not remove backup file'. Any assistance with this would be great - when I click 'save' - what are the functions that RH performs to get to this message?? Thanks A.
Thanks Jeff, the c drive is only a temporary location while I am writing as saving them elsewhere on our network adversely impacts on RH's performance, the whole lot gets picked up and moved on our network once they have been finished.
I just mean when you're actively working on them - they should be kept in as short a path as possible for best results. This "best practice" also applies in Source Control situations too.
Europe, Middle East and Africa