I've got D-Opus 9 installed on my laptop and on my desktop. The laptop version (same on both) however does NOT refresh when I move, delete or edit files or folders in the lister panes, folder trees or anywhere else- I have to hit "f5" each time, and often that kicks me out of the lister pane or some other issue.
I've opened up both on the same table (laptop next to the desktop) and so far I've not been able to find a difference ANYWHERE. Short of loosing my customized laptop version (it's more customized and nicer than the desktop one) I DO NOT want to do a backup and restore from the desktop one to the laptop!
I've checked everywhere I can think or find (spent 3 hours today searching) to no avail...
Is there a box I need to check to have it refresh actions as I make them?
You could check your -> settings -> preferences -> file operations -> options -> »automatically sort new and chenged files«. This box has to be checked.
"auto' sort new..." I think that did it- but I just copied over a restore from the desktop version, so I'll have to restore the old problematic one to check.
everything works fine in explorer (but I hate to use it, wink)
I haven't checked for an update- I'll check that out ASAP, and the change log. V9.0 (and some minor bit) seems to have been rock solid for the last 2 years or right after it came out- never felt the need to update (I figured I'd update once v10.0 went beta and do them side by side or when it was a public release).
Thanks All.
p.s. I'll post if that was the fix- checking that setting, as soon as I can- got a toddler demanding my attention...
You've got plenty of time to post questions here, so the few minutes required to update Opus should not be a problem. It's a waste of a lot of peoples time if you are asking questions on versions that have long been superceded. For all you know, things have changed, been fixed, or are no longer an issue.
Please upgrade to the latest version you are eligible for before posting.
I’m having the same problem with v9.5.6 (OS is 64–bit Windows 7).
The target server is a Nexenta Core box (see http://www.nexenta.org/ — it’s basically OpenSolaris) running cifs on the zfs filesystem.
Any changes to files on this server outside Directory Opus (such as uncompressing files through WinRAR) can’t be seen until I press F5.
Changes made to files on Windows network shares are immediately available as expected.
Possibly related: Refreshing the file listing of any network share (on the Nexenta server or a Windows server) takes a good 15 seconds, regardless of the number of files in the listing.
Windows Explorer functions as expected — i.e. with none of the above issues.
I’ve made sure Directory Opus is configured as requested in this thread.
See the FAQ on troubleshooting "Changes to folders are not being detected", in particular the comments about Samba (since it's running OpenSolaris it will be using Samba).
See the FAQ on troubleshooting "Changes to folders are not being detected", in particular the comments about Samba (since it's running OpenSolaris it will be using Samba).[/quote]
I went through the FAQ already — that’s what I meant by “I’ve made sure Directory Opus is configured as requested in this thread.”
I don’t really “want to try debugging the problem” myself as suggested in the FAQ.
The fact that Windows Explorer doesn’t have any problems detecting changes should be meaningful information to the developers — it should imply that Directory Opus is doing something different than Windows Explorer to detect file changes and that’s where they should be looking for the fix.
[quote="xbprm"][quote="dsb"]
The fact that Windows Explorer doesn’t have any problems detecting changes should be meaningful information to the developers — it should imply that Directory Opus is doing something different than Windows Explorer to detect file changes and that’s where they should be looking for the fix.
[/quote]
Maybe, but if you
what shall the developers do? Come to your house personally?
The steps in the FAQ are meant to narrow down the root cause and help the developers to reproduce the problem in order to solve it rapidly.[/quote]
The fact that there are at least two people experiencing exactly the same issue would imply this is a larger issue than individual configurations.
The developers should determine (if they don’t know already) why Directory Opus handles file listing refreshes differently than Windows Explorer, and then make Directory Opus not handle file listing refreshes differently than Windows Explorer.
If necessary they should setup a similar configuration as myself and the original poster — Linux is free, as is OpenSolaris — and see if they experience the same problems.
If they don’t see the same problems we’re having it would imply it’s a unique issue and personal debugging on the user end would be appropriate.
The problems the two of you are seeing are probably unrelated. Note that the root thread is about a very old version of Opus and many things have changed and been improved since then.
Given that Explorer is not open-source, how do you propose they do that, exactly?
(And I wouldn't want Opus to do exactly what Explorer does anyway. Explorer in Windows 7 regularly misses changes which Opus manages to detect. The fact is that file-change notification is a tricky business on Windows at the best of times, and adding Samba to the mix makes it even more complex.)
Opus has been tested with Linux, OpenSolaris, Samba, etc. The fact is that there are so many versions and configurations of those OS, and Samba in particular, that there are a lot of variables at play. Samba can be compiled and configured with extremely different behaviour. It also depends on which filesystem is being used on the Linux/Unix side, and whether Samba was compiled to use features like change notification, if the filesystem even supports change notification (if it doesn't, Samba has to re-read the directory manually and generate change events; how often that is done is set in a Samba config file and may cause the change delay to be be minutes rather than the usual fraction of a second). Unicode and case-sensitivity issues also come into play and vary depending on the other system an the actual names of the files (and how the same files look to the Unix side).
If they did see the problem it would have been fixed already.
The debugging steps do not take long to do at all.
