Since updating from 9.1.1.0 to 9.1.1.1 DOpus often uses 100% cpu and has to be killed. This happens after uploading/renaming/deleting files from FTP servers when DOpus retrieves the list of files. Doesn't happen everytime but I'd say it's like 70% of the time. Happens with different FTP servers as well.
The problem is still there in 9.1.1.2 and never happened before 9.1.1.1, thus I downgraded to 9.1.1.0 and everything is fine again.
32 bit version btw
Do you have a software firewall running beyond the built-in Windows firewall?
If so, does it use application signatures (i.e. based on the checksum of dopus.exe or similar)?
no, not even windows firewall (nat router)
Now that I'm home I've tried 9.1.1.2 on an FTP server (only non-SSH server I have write access to). I uploaded, downloaded, renamed and deleted a bunch of files. Tried doing it via drag & drop as well as the toolbar, and to Opus itself as well as the Desktop. Inline rename and toolbar rename. Everything worked fine for me.
Is there any similarity between the servers you are connecting to? Maybe the problem happens with particular server software or something.
It might be worth opening the FTP log (Tools -> Output Window) to see if any kind of message is being printed just before, or during, the problem.
If these are sites that allow anonymous access let me know and I'll see if I can trigger the problem by connecting to them. If it's possible to create/provide a test account with write access then contact GPSoftware with the details and they'll almost certainly take a look. Without that, since it seems to work fine for me and nobody else has reported anything similar so far, they will probably be stuck for a way to reproduce or investigate the issue.
I'm seeing the problem with different servers, from FileZilla on localhost to FTP accounts on my server and different webhosters.
FTP log doesn't show anything (or at least I can't see anything as the whole UI freezes when DOpus does this, when I switch to another app and back to DOpus it doesn't even draw any GUI)
With these steps it's 100% repoducable: Upload abc.php by drag&dropping it from left to right lister, then rename the file on the server to def.php
In 9.1.1.0 and earlier there wasn't even a dialog then as no server info had to be retrieved, 9.1.1.1+ show that dialog appearing when data is exchanged with the server and freeze there.
It sounds like you have a firewall issue - what firewall / antispyware / antivirus software are you running, and can you try turning it off?
Nothing changed in FTP from 9.1.1.0 -> 9.1.1.1.
Does it make any difference if you change the Transfer Mode setting for the site (in the Misc tab of the FTP Address Book window)?
I've tried with both Binary and Automatic (which would transfer .php files as ASCII since PHP is in the adjacent list of extensions) without any problems but perhaps the problem is triggered by specific file contents which confuse the end-of-line conversion stuff.
Could you zip and attach an example file that causes the problem when you send it? (Please zip it to prevent anything else modifying it in transit.)
using none
installing 9111 makes it happen, downgrading to 9110 fixes it so something must have changed
nope, doesn't change anything. it also isn't related to the file or filetype, tried with a 1*1px gif, small exe and zip, same there
Nothing has changed with the FTP in these versions. Ans this problem does not appear here, indeed the GP Software servers are updated using exactly the technique you are having a problem with.
It reads like a firewall issue or overzealous antispyware program. The reason you see the older version working is probably because this is cleared to bypass the firewall while when you install the new version your firewall see this as a new program and blocks it. Explicitly clear the new version through the firewall and AS software.
As I already mentioned I'm running no stupid protection software. brain.exe, NAT router and Linux routing server with iptables do the job pretty well for me. Even Windows firewall is disabled.
If you manually F5 both sides of the lister a few times does that trigger the problem? If so, does refreshing either side trigger it or only one of them?
It could be that there's a file in the local side which is sometimes causing problems when that directory is read -- as per this FAQ -- and FTP isn't really involved except that it triggers the directory to be re-read.
Another thing to try: When the problem occurs, load Process Explorer, right-click dopus.exe in its list, open Properties and click on the Threads tab. Sort by CPU and you should be able to see which thread(s) is/are using all the CPU. Select the offending thread and click Stack, then post a screenshot of what you see.
That may indicate which component is causing the problem. (e.g. If it's due to a 3rd party DLL that is loaded into Opus which you have but we don't.)
I think I figured out why it happens:
9.1.1.1 and later try to use Viewer Plugins for FTP files and something goes wrong loading the file. 9.1.1.3 sometimes even crashs when I select a file in the FTP lister.
How can I make DOpus NOT use viewer plugins for content on remote servers? Showing a preview of those, loading them in background is just stupid!
Back to 9.1.1.0 until this gets fixed.
Which plugins or file types trigger the problem?
JPG, PNG, WMV (displays as hex on FTP sites) and Zip files are all fine for me and don't cause the 100% CPU problem you're seeing.
I don't think there is any setting to change it, except for closing the viewer or disabling the plugins that cause the problem.
[quote]Which plugins or file types trigger the problem?
JPG, PNG, WMV (displays as hex on FTP sites) and Zip files are all fine for me and don't cause the 100% CPU problem you're seeing.[/quote]
I think it's the MultiView plugin, had the crashs with php files
9.1.1.0 didn't use the viewer plugins for FTP content and that's the way I want it to be.
Do you get the same problem with local copies of the same files or only on an ZIP site?
If it does work locally, could you try putting the file inside a zip and then entering the zip and viewing it? That uses a similar mechanism to FTP for viewer plugins and might simplify the steps to reproduce the problem.
Could you attach an example file so I can try to reproduce the problem?
9.1.1.0 did use viewer plugins on FTP; I just tested it:
