0.84: Network folders don't auto-update in tree when changed

[vertigo]

XnView: MP 0.84 x64
OS: Windows 7 - 64 bit

Network folders don't update in tree when changed elsewhere (but they do update in right pane)

Effect: Network folder tree may not accurately represent actual state of directory structure, which could easily cause problems, especially if multiple people are using the same network share

To reproduce:
1. Browse to folder in network
2. In Explorer, add or modify a folder in the folder from step 1
3. Go back to XnView and notice directory tree (left pane) does not reflect the change
4. Also notice that it is updated in the right pane

Actual behaviour (bug): The directory contents in the folder tree are not updated to reflect their current state

Expected behaviour: The directory contents in the folder tree should be updated immediately upon any changes, as they are in the right pane

[helmut]

I've tried to reproduce this one but without success:
When creating or renaming a folder on the network drive both folder tree and file list in XnView where updated.

Is the folder that you change using Windows Explorer the folder that you currently browse in XnView?
EDIT: Changing the folder currently browsed in XnView isn't possible - XnView seems to look the folder/files.

XnView: MP 0.84 x32
OS: Windows 7 - 64 bit
Network drive: NTFS file system

[vertigo]

Perhaps it's due to the uniqueness of my situation. The "network" drive I was browsing is my data drive which has my pictures on it. So it's the same drive/directory, just direct access vs access via a network share. And I forgot to edit my step 2, but I actually found in my testing that the same thing happens if changing it in XnView (direct access). IOW, if I open the same folder through the drive letter then scroll down and open it through the network then scroll back up and change something through the drive letter, when I scroll back down to the network access it remains unchanged. I don't have any actually network shares, so I posted this in case, and assuming (I know, I know), it was the same with a true network location. I could try to set up a share on my Surface, but I despise Windows networking, and if you're not having the problem I'm not worried about it, because as I said, it might just be unique to my particular situation, which I only discovered by checking out another bug.

[helmut]

Thank you for your long reply and details, vertigo. I keep this one open for now; perhaps someone else owning a network drive can try this out and post the result.

[CameronD]

This would not surprise me, as I have even had windows explorer not update things changed elsewhere. Sometimes.

But in this case, I could not reproduce the report.
I tried both a real network share, via a mapped drive letter and unc path, and a local drive via drive letter and unc path:
Tests:
copying a new file in : updated file list is automatic
renaming the file : both locations see the new name
editing metadata (file modified date was changed) - both locations showed the new data.

I even tried messing about with an image (using another program) and could not reproduce the original report.

Note: XnViewMP will regard these as two different files and if you do not have your preferences set to automatically update the file modified date when writing to the file, then XnView will not bother to check for modified metadata, thumbnail, etc. because there is no evidence that the file had changed. That would be behaving as expected.

Vertigo,
you will need to be far more precise in what steps you took to make it behave that way.

[helmut]

Thanks for trying and reporting, CameronD.

@vertigo: Could you perhaps make a test with two instances of Windows Explorer? One instance to make the change and the second instance to see whether it updates.

[vertigo]

CameronD,

The issue isn't with the files; as noted in step 4, the contents (i.e. files) are in fact updated. It's just changes to the directories themselves that aren't. So if you have a network share containing F1 (folder 1), F2, and F3 displayed in the folder tree, and you add F4 through Explorer, it will not populate into the list of folders in the folder tree in XnView. If that still doesn't work for you, I can maybe try to make a video later.

[CameronD]

CameronD,

The issue isn't with the files; as noted in step 4, the contents (i.e. files) are in fact updated.

OK, yes, I can reproduce that. In fact, that is a situation that often happens in windows explorer as well, however it is repeatable with xnviewmp, while it is erratic with windows explorer.

To reproduce:

• start xnview in browser mode
• start windows explorer in browser mode - adjust settings so that folder tree is displayed and expanded folders stay expanded.
• in both programs browse to a folder in mapped drive mode and expand the folder tree.
• then in both programs browse to the same folder in UNC mode and expand the folder tree.
• on another computer, or the server, create a new folder in the folder currently open, and another at a higher level (two new folders)

Result:

• In both xnviewmp and windows explorer, the new folder appears in the list for the folder that is currently open.
• in windows explorer the folder is immediately added to the tree in all 4 places: both mapped drive and UNC locations.
• in xnviewmp, the folder tree is not updated, except that I later found an update to the top level mapped drive tree, but it was added to the end and thus not in sort order.
• view-> refresh (F5) does not update the folder tree in xnview, nor does it resort the one it had found.

In fact it seems to be the folder view almost never refreshes for the UNC paths, although the same file via a mapped drive does normally refresh.

Example, in XnViewMP:

• browse to a folder via a UNC path and expand tree
• using a different program, create a new subfolder in that folder
• The current folder list is updated with the new folder, but the tree is not updated.
• dbl click on the subfolder: the list view changes, but the tree is not updated.
• back in the folder above, focus in file list window, F7 (edit->new folder), enter name: file list window is updated, but the tree is not updated - actually, the mapped drive tree view is updated, but the unc path is not.
• find a test folder that is listed in the tree view, select in list window and delete: list window is updated but the unc part of the tree is not updated - while the mapped part is .

[helmut]

Thank you very much for your very detailed description and analysis, CameronD. I've just tried to reproduce this using UNC path (instead of mapped drive) but failed: Everything worked nicely - both folder tree and file list are updated immediately after changing inside or outside of XnView.

Perhaps this has something to do with the file server and its settings?

[m.Th.]

(...)immediately after changing inside or outside of XnView.

The change was made on another computer? (via a some sort of Remote Desktop app or another keyboard?)

Perhaps this has something to do with the file server and its settings?

...aaaand with the network client. It is known that Windozes have problems with refreshes in such scenarios. Now we are rather ok (I think - sorry, I don't have time to test this scenario now) but we have a loooong experience with such hiccups.

Mind you, „server” can become any computer which has a share on it. If this computer has a Vista/Early 7 or even worse an XP (which is a great OS btw) be sure to expect such problems.

XnView MP most probably relies on file system change events signaled by the OS - it doesn't do any pooling and/or date-time checking in order to bypass the OS's events. Hence, any problem in OS, especially in LAN event broadcasting, subsystem which is famous for its inconsistencies, will lead to a „bug” in XnView MP. Of course add on top of this the Qt's own bugs and you will have a very nice piece of cake. I suspect here that Pierre's fault, if any, isn't too big.

Windows Explorer seems to use a secret sauce (NetBIOS? other events? - something like this...) and not only the classical OS created/modified/deleted events of the file system.

view-> refresh (F5) does not update the folder tree in xnview, nor does it resort the one it had found.

For the 1001th time: Unfortunatelly View | Refresh (F5) refreshes only the Thumbs pane. Pls change ZAT caption to „Refresh Thumbs Pane” AND add a new option called „Refresh Tree” - we really need this!

[CameronD]

... I've just tried to reproduce this using UNC path (instead of mapped drive) but failed:...

Perhaps this has something to do with the file server and its settings?

This test is on local machine only, but results via file server are similar.

More detail:

• Machine Windows 7-pro x64 (I am logged in as domain user)
• folder F:\tmp is shared as tmp-on-f, with read-only permission to everyone and all permissions to me.
• open windows explorer, expand F:\tmp and create folder "sub1"
• run xnviewmp, expand F:\tmp in tree
• browse xnviewmp to network \\local-pc\tmp-on-f
• in windows explorer browse to \\local-pc\tmp-on-f and create sub2 in that folder
• in windows explorer:
  • yes: new folder immediately appears in tree view at UNC location
  • yes: new folder appears in file list pane
  • maybe: scroll back upto view F:\tmp and note that sub2 may or may not have appeared in the tree, (last time it did, today it did not)
• In xnviewmp:
  • yes: note that new folder has appeared in the file list pane
  • no: it has not appeared in the tree at the UNC expansion.
  • yes: scroll back up and it HAS appeared in xnviewMP's tree view under F:\tmp
• So the bugs are evenly split between windows explorer and xnviemp, but only windows explorer will allow a refresh of tree contents.

For the 1001th time: Unfortunatelly View | Refresh (F5) refreshes only the Thumbs pane

Yes, it seemed familiar to me, too, but I can't find the older posts.
I have a vague recollection about "when we upgrade to QT5 it might be fixed" . or was that QT4?

Certainly I recall statements about limitations to QT's folder tree system.

[helmut]

... [quote="m.Th.]For the 1001th time: Unfortunatelly View | Refresh (F5) refreshes only the Thumbs pane

Yes, it seemed familiar to me, too, but I can't find the older posts.
I have a vague recollection about "when we upgrade to QT5 it might be fixed" . or was that QT4?

Certainly I recall statements about limitations to QT's folder tree system.[/quote][/quote][/quote]I've just created a new bug report for the manual refresh, see 0.84: Manual refresh doesn't refresh folder tree.

[helmut]

@Pierre:
The manual refresh is handled in a seperate bug report. Fixing the manual refresh would reduce the severity and importance of this automatic refresh.

What can we do about this bug report (automatic refresh)? Postpone it?

[vertigo]

Postponing would probably be fine, but what about just making it low priority? Or is that basically what postponing is here?

[helmut]

Postponing would probably be fine, but what about just making it low priority? Or is that basically what postponing is here?

From my point of view "Postponed" is for all the bug reports that won't be fixed in short/mid term for technical or other reasons. These bug reports are kept in mind but are handled with low priority.
Or in other words:
In "New" there should be only stuff that needs to be reproduced or discussed. Anything that cannot be solved in short or mid-term is moved to "Postponed". (That's my current understanding and explanation, it may change on daily basis )