There was one other post recently about this but otherwise this problem had gone quiet so I don't know why you are seeing it in a project that was not opened before applying the patches.
So turning to FAR, it is not the program that corrupts files. It is what the user does with it. As we usually say, it can fix a project in minutes and wreck it in seconds. That is because the user has not thought about what the search might find. For example, you might search for "class" thinking about your topic content but of course FAR works a code level so it will remove all your style classes as well. That is where the corruption comes in, not the software itself. It's rather like blaming the car for the crash.
If you back up first, there is nothing to lose.
See www.grainge.org for RoboHelp and Authoring tips
FAR is extremely flexible; not only does it ignore spaces and line breaks when rooting out code (a failing of the RH F&R tool), but you can set up variables. This can be important when dealing with strings that include classes, and such.
For example, you can tell FAR to find strings that start with AA and end with BB (all of which contain ???), then replace them with AB???BA.
As Peter says, you must backup your projects first, and then very carefully determine what needs changing without damaging anything else. Another tip is this: some replacement processes are not simply one-time-through runs; rather, you might find that your process requires one or more "prep" runs before running a final F&R.