[Admin note: I've changed the title to include "Clipdiary" in case the problem occurs for anyone else and it helps them find the thread. --Leo]
Two problems with the latest build 9.1.2.0
The copy/move dialog does not always appear. Files still get copied/moved. This problem is sporadic, and I cannot reproduce it at will.
Listers are no longer auto-refreshing when files are copied or moved. Manual refresh works fine.
OS: Windows 7 RC1 (7100)
How are you copying the files? Toolbar? Drag & drop? Copy & paste?
Where are they being copied to and from? Network drives or special system folders at either end?
It's not just that they are copied so quickly that the progress dialog doesn't appear, is it? By default the dialog only appears for operations which take more than a second or so. Can be changed via Preferences - File Operations - Progress Indicators.
What kind of folders?
Please follow the debug steps in the FAQ, Changes to folders are not being detected, and post the results here.
(Or in a private message or to GPSoftware support if you don't want everyone else to see the filenames/paths.)
no folders are refreshing.
copy/move is drag and drop in dual pane lister between regular folders. large files or groups of files, the dialog should certainly come up.
these are problems that appeared when i installed the newest build. i have not changed any settings, and am not doing anything differently than i usually do.
going to roll back now, hopefully it fixes the problems...
Please generate the debug log before rolling back, else there's nothing for GPSofware to investigate and fix the problem. It'll only take 5 minutes.
Also, if you didn't reboot after installing 9.1.2.0 then that may explain the problems.
ok here we go. i tried coping a file into a subfolder that was open in the destination pane. the dialog did not appear. the file copied, but did not show up in the destination until i refreshed the lister display.
bug report during the copy operation is as follows:
[3196] dopus: Notify 030B56C0 Returned 86 bytes, error 0
[3196] dopus: Change 1 to D:\Downloads\New Folder\Blade Runner.mkv
[3196] dopus: Notify 030B56C0 Returned 52 bytes, error 0
[3196] dopus: Change 3 to D:\Downloads\New Folder
[3196] dopus: Notify 030B56C0 Returned 86 bytes, error 0
[3196] dopus: Notify 030B56C0 Returned 86 bytes, error 0
[3196] dopus: Change 3 to D:\Downloads\New Folder\Blade Runner.mkv
[3196] dopus: Change 3 to D:\Downloads\New Folder\Blade Runner.mkv
[3196] dopus: Notify 030B56C0 Returned 0 bytes, error 0
[3196] dopus: Notify 030B56C0 REMOVED
Assuming the "REMOVED" line at the bottom happened when you pushed F5 and not by itself, the log looks normal.
Given this and the progress dialog problem, it makes me wonder if the install didn't go wrong somehow and only update some of the files. Could you go to the /home folder (just type "/home" into the location field in Opus) and add the Product Version column (tools -> Folder Options -> Columns, Programs category), then confirm that all the files have "9.1.2.0" as shown below?
If they don't, reinstall 9.1.2.0 again and then reboot to see if it clears the problem.
they are all correct.
late in the evening yesterday i noticed something was pulling a lot more CPU power than it should have been, as my computer was basically idle. Process Explorer identified the culprit as Clipdiary, and it showed it as a child to dopus.exe in the process tree. both clipdiary.exe and dopus.exe were consuming huge amounts of processing power.
i killed clipdiary.exe and things settled down. i then tried copying files, and all worked as expected.
this morning, clipdiary.exe is under explorer.exe in Process Explorer, not under dopus.exe. copying is working fine.
could this have been the culprit?
Sounds like it was, yes.
The process tree in Process Explorer just represents which process started which. Clipdiary.exe being under Opus just means you launched the program via Opus.
does that mean i should expect a conflict with Opus even if clipdiary.exe is launched by explorer.exe?
I doubt the problem was anything to do with Opus. Clipdiary using 100% CPU was the issue by the sound of it. Opus was probably trying to update the display and show the progress dialog but didn't have enough CPU to do so in a reasonable time.
Seems you're not the only one to experience the problem. See this review:
[quote]Too many times now I've had to stop the process to get access to my other programs back.
[...]
If you do try this, and your other programs stop responding, go to processes in your task manager and sort by CPU usage. Chances are Clip Diary is hogging the processor. Just stop the process to get your access back.[/quote]
sorry, i was unclear. clipdiary.exe and dopus.exe were each using about 15% of my cpu. there should have been plenty of processing power left for Opus to display a copy dialog, or to refresh a file list without me asking it to do so.
at any rate, i'll keep running Clipdiary and see if the problem comes back...
