Delays updating the lister windows

Help & Support
1

I've been using DOpus for about three months. In that time I haven't been able to get a satisfactory 'refresh' of the lister contents.

I use dual vertical display. Currently on ver. 9.1.0.0 but started with, I think, 9.0.0.3.

The problems are around screen updating after moving files between the two lists on screens (the source folder does not update), deleting folders in the folder tree section of the lister (the folder tree does not update, even after F5), and renaming a file or folder (after pressing Return to confirm the edit, the original name appears).

I've looked through preferences but cannot find options to speed up the refresh. I seem remember there was an option for handling folder tree updates in the first version I used but I can't find it now.

Any help would be much appreciated.

2

Does the problem only happen with some types of device, say network drives or Samba network drives in particular, or removable drives?

3

Nudel,

It happens on my two internal disks (120Gb each), about 14 drives defined across the two.

It feels like I have an option like "don't update lister views unless absolutely necessary" set but of course there isn't one as far as I can see.

4

Nudel,

Attached is a Word document showing what happens when I rename a folder.

I make the changes, press Enter and the edited name reverts to its original name. It takes an F5 to see the new name.
071225 - DOpus - Slow,No Lister Refresh.zip (119 KB)

5

Nudel,

I think the problem is ON MY MACHINE! In the context menu, there was a command from another file manager. I've removed that file manager and its context menus and the DOpus lister update problem has been dramatically reduced. I'm now investigating other context menu commands to see if I can eliminate all the lister update problems.

I'll report back when I've finished.

6

Update.

Yes, it is 'my machine' but I've now got doubts it is because of what is in the context menu.

I now think it is because the drive I mainly work with is almost full (98%). What I noticed after writing my last message was that the first few edits worked normally but after a while all the slow responses, I previously reported, had come back. It was a like they was a cache of file changes that were not being processed.

Experiments with another drive with plenty of space show no slow responses.

I'll keep you posted.