When I view a font in the viewer pane I can rename that file without errors. However when a font is shown in viewer pane and I go one up and rename the folder, opus opens the UAC dialog and gives a permission denied error. However I can delete that folder just fine. I think the folder is not locked, but why can't I rename that folder?
With font I mean .ttf or .otf file.
The folder must be locked in some way if it can't be renamed. No other explanation for it.
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.
Yes but if the folder was locked then I wouldn't be able to delete that folder. I can delete it but can't rename it.
Deleting the folder causes the files inside it to be deleted, which causes the viewer to release them first.
The folder is locked in both cases (by the Windows font preview handler presumably).
Ok but is it not a good suggestion to have opus release the file (as it can when deleting) first when rename?
1 Like
Maybe... It's very rare for this to happen though.
@Leo Sadly, this is not a rare case. It's THE one and only beef I'm having with DOpus and it happens a thousand times every month: Viewer locking files and folders from being renamed and (contrary to the discussion here) also from being deleted in some cases. We need to scramble together and map which content types and which operations (deleting/renaming, etc) get restricted.
I made a video that replicates the exact occurrence of the aforementioned issue:
Again, this nuiscance is not isolated to font (*.ttf) previews. A whole lot of other content types renders the same problem. However, interestingly, there are some types, like *.txt files, that won't cause the same issue.
I don't mean to be negative, but to be honest, having to deselect files before renaming their container dirs makes the usefulness of the otherwise excellent Viewer Pane severely questionable.
The reason that text files don't do it is because we wrote the text viewer 
The font viewer is a Windows component, and it locks the file, not Opus. The same thing will happen in Explorer.
1 Like
I got you, @Jon . So, is there really no way to work around this? No hidden backdoor? Seems ridiculous why they'd lock up folders like that.