File pane not updating

Hi,
Apologies if this appears more than once - it seems to keep being bounced!

Currently trialling directory opus 8.0.1.2, and pretty pleased with it. I have one strange problem though, which could end up being a show stopper for me. Frequently my file list panes don't update. This can be when another application creates a file/folder in a directory being viewed, when directory opus itself deletes a file/folder in a directory, and when I rename a file/folder within directory opus. In each case, the display does not represent the directory contents until I ask for a refresh manually.

It seems more likely to happen in a window that has been open for a while, and whilst one window is misbehaving a newly opened one will behave perfectly. Once a window starts to misbehave it never seems to behave properly again.

My machine configuration is windows xp pro SP2, intel P4 processor, 1 gig memory. Can provide list of other running processes if it will help.

To give an example of how bizarre this is, I renamed a folder within directory opus (by clicking on it whilst it was selected and overtyping the current selection). Once I'd changed it I clicked away from it and it reverted to the old name in the file view pane. At the same time, in the cute ftp pro window open behind the opus window, it's local files window did reflect the change I'd just made

We as well have been having this problem, but thought it was just a local to us thing. Can anything be done about it?

This all of a sudden started happening on my machine last weekend and went away the next day.

As coastal has said, I thought it was just my machine acting up again. :sunglasses:

I too see this all the time...annoying as heck! I use Opus alot for FTP and have it not refresh the contents of directory listings even after a time out where it had to reconnect.

I believe this is because Opus caches the directory listings for speed but fails to update the cache when it should.

I've reported this to them but have yet to hear a confirmation on if they admit this problem or not.

I'm having to use the F5 key press all the time to make sure the panels stay current with reality!

F5 refreshes the contents.

T-Man, I believe the others are talking about Opus failing to reflect changes made to local (or network) drives, rather than FTP sites.

Regarding your problem with FTP sites, do you mean that Opus doesn't update the file display to reflect changes that it has made itself, or just that it doesn't automatically reflect changes made to the site by other programs/users? (There's no way for an FTP client to do the latter, as far as I know, except to poll the directory which is considered rude by most FTP site-ops.)

If it's the former, that Opus isn't reflecting changes to FTP sites that it has made itself, then is there any useful information in the FTP log? (Select the Output Window menu option to see it.)

Here is what I would expect Opus to do...

If Opus caused the change to the directory listing, it should always refresh immediately following the action with a fresh update.

If another app caused the change to the directory listing, I expect I should have to refresh manually if I don't change directories. If I change directories...up, down, new FTP site, I expect Opus to refresh it's listing.

If the connection times out, when I refresh or go to another directory up/down, etc...the connection re-establishes by Opus so clearly it should refresh the view.

The only time I would expect to refresh manually is if I have not changed location in the hierarchy or my connection timed out.

However the above is not what Opus does. It caches its listings for what appears to be every single directory I've ever visited recently or ever. It appears to display THAT version of the listing over obtaining a fresh copy!

At this point if any caching is going on, I wish Opus had a checkbox to turn this feature off!! I can't think of a time when I would want that on. Why would anyone want a stale version of a directory listing?? I suspect this has something to do with Opus' ability to detect when the cach listing is out of date. It appears to keep local directory listings up to date, but remote sites, it falls flat.

As for log transcripts, I've sent them in to the Opus people. Haven't heard from them yet.

That is the way the FTP cache works. It's a simple cache for the current FTP site and the recent folders which makes the process much more efficient when navigating an FTP site. It only caches folders that you have actually viewed and all caches are flushed when you close the FTP site Lister or change out of that connection to another or a local folder. The only way a cache can be maintained is if there is still a physical control connection to the FTP server.

When you manually refresh the FTP folder then Opus sends a LIST command to the remote server and dumps the current folder cache and rereads it from data supplied by the server.

This is the way Opus has worked since day one and we have never seen any specific problems such as you describe so I do not know exactly what you are seeing here. Are you using some wierd kind of proxy server which is causing some internal cache problems in itself.

btw: I've not received any reports of this through the normal request for support system. Please report such anomalies in the normal manner so thay can be tracked.

Regards, Greg

So... any of the development team ever experienced this? Any more information I can provide to help a diagnosis? This is happening virtually constantly on this machine. I like directory opus, and would certainly buy it apart from this. As it is though, it renders useless for me what is otherwise an excellent utility

Kev

Are you experiencing this on local or network drives?

Note that by default, for performance reasons Opus does not monitor external file changes on network drives. You can enable this through Preferences - File Operations - General - Detect external file changes on network drives

Local drives. I understand the problem with doing this on network drives, but unfortunately this is happening on the workstations own hard disk. There doesn't seem to be any general problem with the notification service, as if I have another application displaying a folder and have directory opus modify that folder, the other application will register the change and update itself, but opus will not.

Are there a lot of file changes going on in the background (e.g. by other programs to other directories)? I know that, for some notification methods at least, this can cause the change-list buffer given to the OS to fill and miss any changes which happen before the application empties the buffer and gives it back to the OS.

In fact, Windows really doesn't make it easy to reliably detect file changes. :frowning: Even the SysInternals example application is very easily broken in this way if you create the situation on purpose. The only solution I know of is to detect when the buffer was filled and re-read every directory that is on display, just in case.

But it may be something else causing the problem you're seeing as in normal usage that number of changes all at one time is unlikely. It might be worth running FileMon to see what's going on during the times when you see the problem.

No, I don't think that's it. For one this is not an isolated incident - it seems that after being open for a while most if not all opus windows will exhibit the problem. Secondly I can think of several occasions where there was nothing else going on at the time. Finally, wouldn't the fact that other windows browsing the same directory get the notification knock this on the head? The example I gave before had me change the name of a directory in opus, whilst cuteftp had the same folder open (in it's local filesystem window), and cuteftp displayed the change, but opus immediately jumped back to the previous name.

Is that a clue, by the way, the fact that even when opus makes the change the pane does not show the change? I guess not though - presumably in this case Opus doesn't call extra code to update it's display, but uses the notification handling code to do it?

It's something about my machine, for sure. I'm running the trial on my machine at work at the moment as well, and I've never seen it happen on that machine.

I'll take a look at what filemon can see when I get home (kids allowing) - I can see it might potentially give a clue

Thanks,
Kev

Here's a filemon dump taken whilst I renamed a folder within directory opus:

22:06:41 dopus.exe:3356 OPEN F:\Ebooks\3 Physics Books
SUCCESS Options: Open Access: All
22:06:41 dopus.exe:3356 QUERY INFORMATION F:\Ebooks\3 Physics
Books SUCCESS Attributes: D
22:06:41 dopus.exe:3356 CLOSE F:\Ebooks\3 Physics Books
SUCCESS
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\3 Physics Books
SUCCESS Options: Open Access: All
22:06:41 dopus.exe:3356 QUERY INFORMATION F:\Ebooks\3 Physics
Books SUCCESS FileNameInformation
22:06:41 dopus.exe:3356 QUERY INFORMATION F:\Ebooks\3 Physics
Books SUCCESS Attributes: D
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\Physics Books SUCCESS
Options: Open Access: All
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\Physics Books FILE NOT
FOUND Options: Open Access: All
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\Physics Books FILE NOT
FOUND Options: Open Access: All
22:06:41 dopus.exe:3356 OPEN F:\Ebooks SUCCESS Options:
Open Access: All
22:06:41 dopus.exe:3356 CLOSE F:\Ebooks SUCCESS
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\Physics Books FILE NOT
FOUND Options: Open Access: All
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\Physics Books FILE NOT
FOUND Options: Open Access: All
22:06:41 dopus.exe:3356 SET INFORMATION F:\Ebooks\3 Physics
Books SUCCESS FileRenameInformation
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\3 Physics Books IS
DIRECTORY Options: Open Access: All
22:06:41 dopus.exe:3356 OPEN F:\Ebooks\ SUCCESS Options:
Open Directory Access: 00000000
22:06:41 dopus.exe:3356 CLOSE F:\Ebooks\ SUCCESS
22:06:41 dopus.exe:3356 CLOSE F:\Ebooks\Physics Books SUCCESS

22:06:41 dopus.exe:3356 CLOSE F:\Ebooks\Physics Books SUCCESS

Can't see anything particularly out of the ordinary in it