GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Opus 12.6 - File list not updating for local/network/ftp folders


#21

Did you read that in a rush too? Your answer does not fit the question. He asked if a dump was created automatically (you have to check the dump folder), not if you manually created one (which you say you did not).

If yes, don’t worry, happens, but go find that dump.


#22

Thanks for the pointer

I don’t see that it’s obvious from his actual text that he was asking about an automated dump having been made. However, I do see that the page he linked to mentions an automated dump being made and one was in fact made. I’ve emailed it to crashdumps@gpsoft.com.au

Thanks, again


#23

I think I have some more information about this problem, in case it helps.

We have a programming environment that uses DDE to talk to MS Excel (it reads/writes data to/from Excel files). We’re also having a problem with that which started the same day I upgraded to Opus 12.

It appears that whenever Opus is running AND is currently exhibiting the intermittent File List update issue the DDE communication between our programming environment and Excel is VERY slow (minutes compared to the usual seconds). During this period of delay, if Opus 12 is closed then the DDE communication seems to recover. Conversely, when Opus 12 is running and isn’t currently experiencing the File List update problem the DDE communication seems to be normal.

I don’t know what’s really involved behind the scenes when using DDE to talk to Excel but I’ve seen indications that COM objects are part of it.

I don’t know if that helps point to a particular direction but I thought I should mention it, just in case it’s helpful.

Jason


#24

Hmm, interesting. If you’re able to spend some time testing it, one thing you could try is to run Opus elevated (shut it down completely, then start it using Run As Administrator - it should show ADMINISTRATOR in the title bar to confirm).

(If Excel or something else is broadcasting random messages around maybe Opus is misinterpreting them - running it elevated will stop non-elevated processes from sending messages to it).


#25

I’ll give it a try tonight. If DDE is somehow related to this then it would be consistent with the intermittent nature of the Opus problem; we periodically use DDE (quite often but not continuously).


#26

That crash looks like a known bug in Windows 7, which also affects Explorer:

Microsoft have a hotfix here:

https://support.microsoft.com/en-us/help/2494427/windows-explorer-may-crash-randomly-when-the-network-discovery-state-i


#28

I posted this as a reply to the wrong message, sorry. Re-posting it now

Thanks, so I take it that crash doesn’t seem to be related to our auto update issue.

Regarding the request to see if running Opus as an admin seems to help. Recall that this is a Windows Server 2008 R2 application server on which many other people are also running Opus. Everything I’ve described so far happened to me when I’m logged on to the server with admin credentials already. When I select to run Opus ‘as an administrator’ it looks exactly the same as when I run it normally (there’s no ‘ADMINISTRATOR’ in the title bar). Opus.exe is nearly always running under some other user’s credentials at the same time. Is that a problem for what you were asking me to check?


#29

It’s possible the crash is tied in to the other problem, but also possible it’s unrelated. Installing the Windows hotfix for it makes sense either way, but I wouldn’t bet on it solving both problems, unless we’re really lucky.

It sounds like UAC is not enabled on the server, which means we can’t use it to test the theory that something is confusing Opus by sending rogue window messages to it.

I will see if I can get the version with extra debugging made today, as that seems the best bet for working out what is happening at the moment.


#30

Yes, UAC is disabled on the server. I disabled it because was interfering with map ‘app’ in Outlook 2013, as I recall. In any case, it is off intentionally.

Thanks for working on a debug version of Opus to try to find the source of this issue.

Jason


#31

The special debug version is now ready. I’ve sent a private message with the details to jproos (and will forward to tbone as well, in case it helps with his similar issue).

Many thanks for your time and help diagnosing this problem!


#32

I expect to be deploying the custom debug build tonight and hopefully generating useful debug information so I can reinstall the official 12.6 build.

With my luck, this version will not exhibit the problem but will be annoyingly slow due to all the debug activity.:roll_eyes:


#34

I think yes, folder updates for me do not work whenever the %G placeholder in the titlebar resolves to {xxxxx-…-yyyy} volume ids instead of the actual UNC path the folder is on

This doesn’t seem to be happening for me.


#35

My users didn’t all cooperate last night so I had to reschedule the install of the custom build for tonight. I’ve installed it and generated a debug log showing some activity that didn’t appear in the Opus file list.

I emailed the log to the crashdumps email address.

Hopefully the log file sheds some light on the situation.

Jason


#36

Many thanks for generating the log for us!

Focusing on the test_<date>_<time> folders you mentioned in the email, the log seems to show that each one was deleted ~5 seconds after it was created.

(I’ve condensed the log format, removed the lines in between the ones I want to focus on, and substituted X:\opustest for the parent path, in case it was anything private. Names of created folders were kept the same.)

11:05:35 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-05-35)	
11:05:40 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-05-35)	

11:05:40 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-05-40)	
11:05:45 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-05-40)	

11:05:46 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-05-45)	
11:05:51 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-05-45)	

11:05:51 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-05-51)	
11:05:57 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-05-51)	

11:05:58 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-05-56)	
11:06:10 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-05-56)	

11:06:10 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-06-02)	
11:06:14 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-06-02)	

11:06:14 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-06-07)	
11:06:21 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-06-07)	

11:06:23 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-06-14)	
11:06:24 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-06-14)	

11:06:24 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-06-21)	
11:06:28 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-06-21)	

11:06:28 PM -- FILECHANGE_CREATEUNKNOWN (X:\opustest\test_2017-09-21_23-06-26)	
11:06:32 PM -- FILECHANGE_DELUNKNOWN (X:\opustest\test_2017-09-21_23-06-26)	

Does that sequence of events make sense to you, based on what was happening on the machine? Or are the delete events spurious?

If the events are correct, then it makes sense that Opus would not show all of the folders, since it only updates the lister every few seconds (to avoid using too much CPU and making the file display constantly jump around while you’re trying to use it). So some of the folders would be created and deleted between updates, and never show up. Others would be created, appear in the lister, then deleted and disappear after the next update.

On the other hand, if the folders were not actually deleted then it looks like something is generating incorrect change events that say they were deleted.


#37

Leo, yes the deletes are real. I was running an automated process that creates folders with a name that reflects the date and time the folder was made and then deletes it 5 seconds later then waits a few seconds and starts over for something like 20 iterations. This is a process I wrote specifically for this issue with Opus. It let’s me generate activity automatically that I can watch for without having to be busy generating the activity myself.

Normally, folders that are created appear instantaneously in Opus so I didn’t expect that creating them and then deleting them 5 seconds later would be a problem. When it’s not exhibiting the problem I see every folder before it’s deleted.

Do you need me to revise this process and try again?

I should also mention that watching the output of this process is not what led us to notice the issue with Opus. the users themselves create files and folders or rename files and folders and minutes later those changes are not reflected in Opus 12. They were always visible immediately for us with Opus 11.

Jason


#38

Yes please. If the folders were being deleted so soon then the existing test/logs aren’t useful, unfortunately. The create and delete events may all cancel each other out in pre-processing before anything reaches the file displays.


#39

ok, that doesn’t line up very well with my experience with Opus (changes not appearing immediately) but I’ll do it again without the deletes this time. I’ll have to schedule another maintenance window on the server.


#40

They only appear immediately if the folders are created by Opus. If they are created outside of Opus, the changes are batched up and processed every few seconds.


#41

Ah, that would explain the deviation from my experience which is pretty much entirely based on actions taken within Opus.

Thanks for helping me make sense of that.

I’ll be trying for a maintenance window this weekend sometime.


#42

I’ve scheduled a maintenance window this Saturday night. I’ll reinstall the debug version and generate the debug logs again (this time not deleting the folders that are being created)