Yes, the viewer pane occassionally keeps a lock on the current file. This did happen much more frequently before Leo took a look and improved the code.
Have a look here:
Since Leo's last changes this bug only happens 10 times per day on our systems instead of 10 times per hour (as before). We don't use any other plugin than the text viewer (which even shows binary files in this mode) and it's always DOpus blaming itself to hold a lock on the file (see screenshot). In such a case (couldn't delete a folder/file) I just have to update the viewer plugin (by selecting an other file) or step back/forward to let the viewer release the lock.
For the same reason there are other tools affected. For example often WinRAR can't remove the files after archiving because DOpus viewer plugin still hold a lock on an affected file. Thus I have to close DOpus or adjust the viewer plugin and remove the files manually. There may be some file types requiring to keep the file open but I don't know why the text viewer plugin needs to keep large files open. I would prefer if it always closes the file instantly after the viewport was altered (which triggers a read operation) to avoid these access conflicts.
