Is it OK to swallow all exceptions except the critical ones in certain scenarios?

It is ok to swallow exceptions if you want your program to be undebuggable and admins to hate you.

You need to at least log the exceptions at a lower log level debug, trace, fine or whatever.

It will help in debugging issues, understanding how program works, or why something didn't happen.

The only exceptions that can be swallowed are these that absolutely don't have effect on the app which are very rare (e.g. sleep interrupted exception). See this nice article.

Now in your example you are not completely swallowing exception but printing message while discarding the stacktrace.

Just make sure that exception message contains information about source and destination of copying so that this can be debugged by the user. Also depending on your app, it might be useful to know which part of the app code is doing the copying. Sometimes it might be needed.

This line worries me a little...

If copying failed I don't care if particular exception was FileNotFoundException or an IOException "Not enough disk space" exception or something else

Not so much the FNF exception but more with the "Not enough disk space" etc. - these are the sort of exceptions you probably don't want to ignore. Reason being, if there isn't enough disk space then, in theory, your app is going to fail eventually. This is actually one of the main reasons you shouldn't catch general exceptions because you effectively mask bigger problems like these.

On a more general note, and to answer your question more specifically, it's perfectly fine to catch a more general exception where you are confident it won't have any major implications with your app nor, as mentioned previously (and I re-iterate for good reason), won't mask any bigger/more serious issues.

It's okay to swallow specific exceptions in particular cases, but in practice it depends on the use case.

I recommend handling exceptions, you can handle and use the AppDomain.UnhandledException event for unhandled exceptions and inform the user about what happened.

From a debugging perspective it doesn't really matter, as long as you have access to the code, since you can enable to break on all common runtime exceptions in Visual Studio. (Debug -> Exceptions -> Common Language Runtime Exceptions -> Check the left checkbox)

I would never depend on a list of critical exceptions, because you don't really know if the list is complete.

The reason it is generally advised to not swallow exceptions is that it can hide bugs. For example, you are doing something other than doing a File.Copy: you are doing string processing as well (strFile + ".new"). This cannot throw (except for OOM), but if the calculation was more complex, you might have hidden a bug.

In this case you should probably move all calculations out of the try-block. Then it is OK to swallow any exceptions. I'm in the habit of logging them in case I still made a mistake despite being careful.

The rule to not swallow needlessly is there to protect the developer from his own fallibility. If you are reasonably sure that everything is alright then you don't need to follow the rule.