Eager progress bar appearance problem

Since two or three minor versions of Opus operations that require displaying a modal dialog display also frozen progress bar window. For example if I hit delete on a file I am presented a dialog to confirm deletion. Without clicking anything, after a small delay, progress bar appears which obviously stays on 0% until I accept deletion. This produces two windows (also seen on Windows taskbar) instead of one with just a confirmation dialog. Presenting progress bar at that stage makes no sense as it will be always stuck at 0%. The same happens on rename operations, move as and all that require user input to start. That wasn't the case two or three minor versions ago. This behavior was introduced together with a problem of closing a lister causing canceling the operation. That problem was already fixed but eager progress bar displaying stayed.
Is there any way to disable this behavior and display progress bar once operation has really started?

I'm using Opus 12.19 64bit stable on Windows 8.1.

Please try the latest beta and see if it still happens for you.

In newest beta it does not appear on deletion but it does on other operations like copy as, move as etc.

What settings do you have on Preferences / File Operations / Progress Indicators ?

I'm pasting my settings below.
Settings

Just for your information:
The problem still appears on latest beta but now only when related file operation involves more than one file (for example when copy-as two files or selecting two files and deleting them).

I haven't been able to reproduce this unfortunately. Would you be able to email a copy of your configuration (via Settings -> Backup & Restore) to crashdumps@gpsoft.com.au so I can try with that?

Done.

... but got e-mail reply with following message:
Diagnostic-Code: smtp; 552-5.7.0 This message was blocked because its content
presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0
https://support.google.com/mail/?p=BlockedMessage to review our 552 5.7.0
message content and attachment content guidelines. m16si241907pgj.574 -
gsmtp

Did that come from your outgoing server?

No, from your hosting.
Full text:

This is the mail system at host pdx1-sub0-mail-mx59.g.dreamhost.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. If you are a current customer of DreamHost, please contact our technical support team here Sign in · DreamHost If you are not a customer please use our contact form at. Web hosting, VPS, dedicated hosting contact DreamHost If you do so, please include this email in your support ticket. You can delete your own text from the attached returned message. DreamHost Email Support leonudeldavidson@gmail.com (expanded from crashdumps@gpsoft.com.au): host gmail-smtp-in.l.google.com[74.125.197.26] said: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0 File types blocked in Gmail - Gmail Help to review our 552 5.7.0 message content and attachment content guidelines. c1si267071pfj.196 - gsmtp (in reply to end of DATA command)

Are there any exe or dll files in your config backup? (e.g. If you have some companion utilities copied into /dopusdata/User Data then they'd be included in the backup. You'd know if you had done this, so don't worry if that doesn't mean anything to you!)

GMail won't allow any attachments that are exes or DLLs, or archives containing them (it's very annoying for developers!).

You can send the backup via private message if that's easier.

I don't think it's the attachment contents issue as it didn't pass even if I put it in encrypted 7zip.
Anyway I've send you the config using private message.

1 Like

The private message worked, many thanks!

GMail also blocks encrypted archives because they can't see if there's an exe inside them. (If the backup was encrypted originally, that might also be why.)

GMail's attachment policy is pretty annoying at times, with no way to say "I know not to run random files, please don't block things".

Do you still see this problem in current versions of Opus?

I've done a test with the config file you sent (many thanks!) and Opus 12.22.3 (which was not out at the time, of course), and it seems OK:

Please note that in one of the posts above I clarified it happened only on selecting multiple files for operation.
The problem does not occur to me any more because I switched from Windows 8.1 to 10. It had to be related to that Windows version, I suppose. I'm still using the same config on my new OS (exported from Opus and imported back again) so no changes here.

1 Like