Empty Folders left after Move operations

[m.Th.]

If one has several folders with photos (~200 - 900 / folder) the Move operations will leave one (rarely two) empty folder back (usually the last one). Most of the time the remnant folder is 'locked' and it cannot be deleted. One needs to exit/restart the XnView to delete it.

Several characteristics:
- The source and the destination are on different drives (if it matters)
- There are NO 'root' files involved in move. (IOW, always I move folders which have files inside - I don't have a selection which includes files also. My selection is always 'Folder1', 'Folder 2' etc. and NOT 'Folder 1', 'Img_1000.jpg' etc.

[m.Th.]

The same phenomenon appears when we have big sub-folders. They are left in the source root.

How to reproduce:

Have the following structure:

c:\myRoot\foo
c:\myRoot\foo\sf1 - with ~ 500 files
c:\myRoot\foo\sf2 - ~ 500 files
c:\myRoot\foo\sf3 - ~ 500 files
...

Move the 'foo' folder to d:\myDest

Expected:

'foo' with its entire subtree is copied to destination and deleted from source (IOW moved)

Actual:

'foo' with its entire subtree is copied to destination, the files are deleted from source but the empty folders are there.

[m.Th.]

...also something more:

In the above use case the ghost 'foo' folder is inaccessible if the program is still open.

IOW if I do a Move operation AND the folder remains there AND I do not close the program AND I go to Explorer (or to any other program for that matter) and I try to enter in that folder it throws an "Access denied". If I close the program the folder disappears 'magically'. Perhaps you have a sort of lock of that folder (in a thread?).

[m.Th.]

...another related phenomenon:

Sometimes the empty folder(s) left cannot be deleted no matter what the user does. Closing the XnViewMP, deleting from Explorer, restarting Windows does not help. Neither entering in safe mode. Always the same message "Item not found / access denied"

The only way which always works is using the command line with elevated rights and deleting the 'rebel' using the short file name (8+3) NOT the long one (ie. del testf~1 and not del 'Test Folder')

See more at the following links:

http://www.sevenforums.com/tutorials/79 ... elete.html
http://windows.microsoft.com/en-us/wind ... =windows-7


...more and more I'm convinced that there is a lock conflict between 'something' from inside of XnViewMP which tries to update 'something' while 'something else' from inside tries to delete it.

[xnview]

See Issue 105 for current status and details.