When opening a directory sometimes Directory Opus seems to lock it and other programs on the computer cannot write to it anymore. This is specially evident when I scan documents to the computer via a printer/scanner. Once the first document is scanned Directory Opus is opened (as the default file explorer) and the scanned document is shown, however any further scanning results in errors unless Directory Opus is closed (File/Exit Directory Opus) every time after each scan. This has happened with different computers / versions of windows / version of Directory Opus.
That sounds not like an issue caused by Opus. Otherwise we'd see a lot more complaints in that direction, here in the forum. You could try some of the trouble shooting tips in the link below. Most likely some AV scanner, or other program or shell extension may cause those effects.
[url]Crash, exit or high CPU when viewing certain directories]
What do the errors say exactly?
It isn't generally possible to lock a folder from changing (unless the permissions are modified, which would not normally be done and is even less likely to be undone by exiting). I suspect something else is happening.
Is the viewer panel in use?
What type of files are in the folder and being scanned?
Which software is doing the scanning? And if you leave Opus open but restart the software, does that also clear the blockage? (If so, I have an idea what is happening.)
Thank you for the assistance.
The issue occurs when I scan documents with an HP Printer/Scanner. The files format are PDFs.
The printer scans the document, generate the PDF file and then sends it to the computer in the Document folder, also opening the default File Explorer program (Directory Opus) showing the Documents directory.
At this point if another document is scanned the printer generate an error (both on the computer and on the printer screen) indicating that it cannot access the computer. Resetting the printer and closing and opening the scanning software on the computer does not work and the same error keeps appearing.
What works all the time is Rebooting the PC or closing Directory Opus. It is the fact that closing Directory Opus works all the time that is pointing me in its direction.
If the viewer pane is open, try closing that in case the PDF viewer on your system is blocking the PDF scanner in some way.
If the viewer is already closed, the problem is likely caused by a shell extensions some PDF software (maybe the same software doing the scan) has installed, which is loaded into Opus.
You can use ShellExView to get an overview of the shell extensions installed on the machine. I recommend going through the list and disabling anything related to PDF or the same software/vendor as the scanning software, then reboot and see if the problem remains. If it is gone, try re-enabling a few things at a time until the problem comes back.
I'd give the opposite advice. If you close file handles without knowing how they will be used by software that thinks they are still open, it can have random results, including things being done to unrelated files if the handle value is recycled.
Unlocker can be useful as a last resort, but it's not a good thing to use routinely. It's better to work out what is causing the lock (probably a shell extension in this case) and fix or prevent the problem, or to exit the process that has the lock if needed.
Windows Confidential: Forcing Handles Closed from TechNet magazine goes into the issue in more detail.
You're right, but Unlocker also shows which file is locked and by what process - so may be used as information tool.
I'm seeing something similar to this quite often (v12.11 currently), it is not easily reproduced sadly. I've been creating directory hierarchies for build systems which involves creating directories and navigating about editing the directories names and structure, copying directory trees etc. Every once in a while Dopus will lock a directory so I can no longer delete it. I have to quit it, terminate the Dopus processes using task manager and reopen it again in order to progress. These are freshly created directories, it is definitely Dopus that is locking them, no preview or metadata panes are open, often there aren't even files, just directories.
It's probably not Opus itself but a shell extension. If Opus itself was in the habit of locking directories we'd have endless threads here.
Tracking down the exact source of the locks may require logging with Process Monitor until the problem happens, them examining the log (and call stacks it captures) to find where the folder was opened but not closed. We can help with that if logs are provided.
Thanks for the response.
I have Tortoise SVN which runs a TSVNCache task for icons and has been known to interfere with processes, but usually only temporarily and this is permanent, can't think of anything apart from that as far as shell extensions go.
If I get a moment I'll try to find a cause and come back to you.
1 Like