XnView Software

XnView MP 0.61

When you RMB on a folder *IN THE TREE* and select "Move to...", it will actually move it to the desired location, but it will not refresh the tree nor the window content appropriately, so it looks like it didn't work (while in fact, it did).

However, if you select a folder *in the window*, RMB and select "Move to...", it will do the action and actually refresh the tree and the window.

On windows?

More (complementary) info here: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28450

My specs in the signature.

...btw, it doesn't matter if one chooses to Move the things from the Folder Tree or Thumbs Pane. Istm, the bug is related to the fact that one moves ONLY folders not root files also. Also, it can be something WRT syncing with the delete engine - from an user POV the bug appears mainly when there are many/enough photos in the moved (sub)folders.

you have the same problem with folder treeview or thumbnail view with 'move to'?
I've tested and the full folder is moved

xnview wrote:you have the same problem with folder treeview or thumbnail view with 'move to'?
I've tested and the full folder is moved

Yep & Yep.

Yes - the same problem. ...and... Yes - It might work for you. Also for me works some times. But I found that the conditions for http://newsgroup.xnview.com/viewtopic.php?f=60&t=28450 are the most 'favorable' for the bug. Istm that we see a heisenbug due of a race condition.

Besides of the info from http://newsgroup.xnview.com/viewtopic.php?f=60&t=28450 I think that's a problem with the background thread which updates "something" - thumbs etc.

For ex. sometimes I encounter a "file already exists" dialog (you know, the one with two images and 'Skip, Replace, Rename' buttons but this dialog does NOT appear because a normal image file already exists on destination but because the '.' file (current dir file) already exists there (???). It shows me this name as the source and destination and also, instead of the images, in the dialog appear two empty (black) areas.

The same(?) problem in other use case is reported here: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28466

Also, speaking of this, bellow is a very disputable thing:

1. Go in the Folder Tree to a folder of your choice. Be it c:\foo. Make sure that in the right (thumbs) pane the thumbnails appear.
2. With the c:\foo selected, right click on it and choose 'Move To'. Move the folder somewhere else but on another logical drive (eg. D:\, E:\ etc.) in order to force a copy + delete rather than a simple relink in NTFS directory structure (thing which happens if we do a move on a same logical drive).
3. Watch at the contents of c:\foo while the program moves the files - you will see that the thumbs disappear one by one due of move operation. (Do this in a folder with big photos/slow HDD in order to have time to see what's happening).

While this behavior is theoretically correct, there are several issues here:

- One can be an "accidental" collision / lock with the watching thread - thing which can be the essence of the bug which we discuss here.
- Updating continuously leads to a big slowdown to the entire process.

Hence the cure for all these problems might be to disable the watching thread and re/enable it after the transfer operation completes. Of course you will force a re-read on the source dir.