On the weekend I started to maintain my music collection and my tagging tool (MP3Tag) showed many access errors due to a file that was still opened by DOpus viewer pane even if the DOpus last access time was minutes ago. Thus for each access error I had to return to DOpus to manually browse away from the files in question to select any other (not affected) file or I have to permanently close the viewer pane.
Wouldn't it be nice to let the viewer pane release the current file handle (close the file) after a certain amount of time without an actual read access (e.g. 10 seconds -> configurable?).
Since files can be opened so quickly I think it would be more convenient to open the file again if the user updates the viewer pane's scroll position instead of keeping the file open indefinitely. Alternatively it would be fantastic if DOpus releases the file handle if the lister window lost the focus (even if the idle timer hasn't been expired yet).
Since the file content is typically kept in the file system cache the actual open/read action should be fed by memory only. So I would expect a lag-free user experience even if the file has to be opened each time the user updates the viewport position.
On the other hand this would solve so many access problems (WinRAR file deletion, MP3 tagging, image saving, etc.) that occasionally appear due to a misplaced DOpus viewer pane (that may have been idle for hours).
It is up to the individual viewers whether or not they lock files.
In the case of MP3 files, its outside our control (the viewer is likely to be Windows Media Player or Microsoft's preview handler, depending on your configuration) except that you have the option of telling the ActiveX plugin to create a temporary copy of the MP3 file and open that instead of the real file.
Sorry to be a little bit imprecise. As you might remember I only use the text-viewer plugin in text/hex mode. All other viewers are disabled here to prevent accidental opening of files that may be infected with malware (PDF, DOC, etc.). This is a recommendation of out IT policy to protect our intranet from infections.
In other words everything I wrote does only belong to the text/hex viewer pluing that is the default if any other plugins are disabled.
Just close the viewer. What's the point of having it open all the time, showing MP3 files etc. as hex data? Reclaim the space it uses on your screen, and avoid the problem of large files being locked by the hex-viewer by closing it if you are not using it. You can toggle it back on instantly when you do need it.
(Alternatively, you can also turn off the hex viewer.)
80% of the files I have to deal with at work are source code files or plain text files. Thus it's comfortable for me to have the viewer open all the time. Anyway I just wanted to post a suggestion how the current behaviour may can be improved by not loosing any functionality. Personally I think it's more friendly to other apps if the viewer doesn't keep a handle open to the current file. Particurlarly if the handle actually isn't needed since the file can be opened again without any noticable delay (if needed).
To be honest I love the viewer so much, that it would be fantastic to get some more features (like URL handlig or syntax highlighting).
I know this is an old thread, but I seem to be having nearly the same issue. In general I work as a software developer, and as such the Hex view is quite useful for me to leave open. I run at 3840x2160 with fairly small fonts, so screen space is more than available for me, and as such I'd prefer not to constantly close the viewer pane. But, often I'll look at a file I plan to work on, leaving it selected, as soon as I try to make changes in whatever app I'm using I get errors because it is write-locked by a viewer. When it hasn't happened in a while (like today) it can take me over a minute to figure out why it's locked (also like today, hence my search for a solution).
I'm in Dopus 11.19, so perhaps there is already a workaround that I'm just not seeing in the forums. If not, then I second the idea of having the viewer release the file (or never lock it to begin with as it's only a viewer it shouldn't need exclusive access).
Most things won't write to a file if anything has it open for reading, and the hex viewer only loads the file in chunks (unless it is very small) so it is able to handle very large files without loading the whole thing into memory at once.
You can turn off the hex viewer if you don't need it. Most of the other viewers do not keep the file open at all, since they don't need to.