File search return error

That is an excellent point mentioned by @steve. 2% of CPU is consumed by client & it having to do other tasks.
I have done several extensive tests and have found out that 90% of the times, its best to depend on native Windows functionality. So lets say you want to search for files, run dir command. That way you not only bypass the 2% limit, you do not get errors too and run a much more stable function call.

I am trying to shift my focus onto powershell commands via BigFix, but till the time being. When CMD can do the work for you… why depend on inspectors?? Batch scripting is simple and a good friend.

It is best to use Inspectors when you can and it makes sense because they are read only and do not require running code on an endpoint. Inspectors are also cross platform in some cases, which is also useful.

Using an inspector to search the entire disk or most of it does not make sense and is not a good idea. This point is made in many of the other threads I linked to.

You don’t need to use PowerShell to do this, but PowerShell is a good option for many things and could be used for this. There are other native Windows tools that would also work.

Running a script on a regular basis and then using a property / inspector to read the results is a great way to work around a missing inspector.

For copying and deleting “Long Path Tool” software should be try, many articles refer this for such solutions.

Can you provide links to what you are referring to? Your statement is a bit hard to follow.

Is there any workaround to skip files/folders containing illegal names?

Not currently. You could use the find file inspector ( https://developer.bigfix.com/relevance/reference/folder.html#find-file-string-of-folder-file ) to filter things so you don’t hit these bad files. It would be good to have an RFE though I’m not sure if we should change the existing behaviour to skipping bad files.