Wrong file deleted/moved/copied with queue

[gogo167]

This bug seems appeared in all versions(tested 6.53, 7.56, 8.0RC2), and the worst case is wrong files were deleted (this is my case, however, recovered )


Reproduce it: Copy using Queue feature:

1) LeftPanel (source) > highlight/select any single folder (but not the 1st folder)
2) RightPanel (target) > goto any directory
3) <F5> copy
4) <F2> queue
5) !Before the background queue bring up, quickly change the RightPanel(target) to other directory (by tabs or by driver button)
6) Wrong folder/file copied. In my case, it copy the LeftPanel's(source) 1st folder. It only created the folder, content not copied.


- the main key is: change target panel before queue bring up

- other similar operation may also lead to unexpected result, like move/delete, select file instead of folder for copy, quickly change LeftPanel instead of RightPanel... I certainly sure last time(two months ago) wrong deleting some files is triggered by this kind of operations, I stopped the queue half the way and try recovery.

- it will be more easily reproduce this by using slow respond devices, like network drive, usb drive, heavy loading CPU, and in virtual machine/PC environment...


May be the following report related:
Queue copy created directory instead of the file
ghisler.ch/board/viewtopic.php?t=20076&sid=e7ab19d3bab3c5d331efbe0b45058f92

[umbra]

I cannot reproduce it. Are you sure, you are able to do step #5? In my case, TC won't even allow me to do anything with its main window, until the BTM's window is fully loaded.

[Dalai]

I had this problem several times with TC 7.56a when the system came out of hibernation and TC was still being swapped back to RAM. I moved some files from my server (LAN) and the result was that the wrong source file was moved to the correctly named target file (with the contents of another file). I've had no loss of data or anything like that because I saw the error and reacted quickly enough to cancel the transfer.

I no longer have this wrong behaviour since the update to TC 8.0 as its BTM is loaded much faster compared to previous versions and the correct files are loaded to its transfer list. So I don't know how gogo167 was able to reproduce this behaviour with TC8.

Regards
Dalai

[gogo167]

I don't know why I can reproduce it easily, may be following can help:

- according to Umbra's comment, my setting "Calc space occupied by subdirectories > before copying/deleting" is disabled

- according to Dalai's comment, I usually use hibernation to turn off my computer, only cold boot once each month. I had noticed that hibernate causes problem in some other apps like: ProcessExplorer(problem in time counting), ...
Just want to mention I use hibernate most the time, not meaning hibernate causes problem in TC.


I use VMware, and easily reproduce it when copy file from Client machine to Host machine, it got ~2 seconds before BTM loaded.


My config: WinXP SP3, Pentium4 2.8g (single core), 3g RAM, 3 HDs(250g + 320g + 2T, each got 2 partitions)

May be I can take some pics or video if needed.

Below another link related:
BTM copies wrong files when tab closed quickly
ghisler.ch/board/viewtopic.php?t=28571

[gogo167]

I find the logic, here's the update:

(modi in post 1)

5) !Before the background queue bring up, quickly change Any panel to Any directory (by tabs or by driver button), the NewDirectory will become the Source, if no file/folder is selected in this NewDirectory, the first item will be auto selected for copied/moved/deleted. (it is possible for the NewDirectory had file selected if change by Tabs)


It seems the foreground TC not logging source/target info, and let the BTM to collect info itself. Is it true?

[ghisler(Author)]

I'm sorry but this isn't TC's fault - just do not change directories until the copying has started. I can try to disable the dialog boxes while the BTM is starting up, but this may have other unwanted side effects...

[Hacker]

BTW: BTM copies wrong files when tab closed quickly.

Roman