Ok, it also won't show if a folder is locked because something inside it is locked.
Then, unfortunately, there is not much use from this approach.
The current approach updates the database only once every 5 seconds. It is not that bad. You can consider closing DOpus if you don't want to use it. You don't have to keep it in the background.
No, I'm afraid I can't do that 
.
My interest was genuinely more technical curiosity; I don't really have the problem of deal with locked files often enough to need a program that does stuff every few seconds.
I'm still wondering how LockHunter does it, since it doesn't need to run any indexer or similar in the background; in fact, the portable version doesn't even seem to use a service. And when you run it, can get the information at an acceptable speed.
I have released a version 2.0 of DOpusScriptingExtensions.FileLockingInfoProvider:
Releases page
Changes:
The DirectoryOpus-FileLockingInfo-columns-and-dialog.js doesn't need to be updated.
My interest was genuinely more technical curiosity
Ok. It is always good to learn new things.
I'm still wondering how LockHunter does it, since it doesn't need to run any indexer or similar in the background
They do it the same way I do: they request all handles and modules in the system and use the kernel driver to get the file names.
My code is not much slower. From the log that you gave me, I see it takes 0.5 seconds for the database to update. Also, I have to do it via a Windows service, which adds extra cost due to inter-process communication and serialization/deserialization.
LockHunter only needs to show it for a single file and do it all in the same process. Thus, they can do it faster. I have to create a database of all handles so that I can look up every file instantly.
I have released a new version of the script.
Changes:
I have released a new version of DOpusScriptingExtensions.FileLockingInfoProvider. You don't need to update the script.
Changes: