+[8.50b5] Background copy not aborted on TC exit

[MVV]

I start copying 1GB file to my slow USB stick, click 'Background', then close TC and confirm that I want to stop background operation. TC doesn't break operation, I see file on the stick and I see that TC is still not closed and it still writing file (in Process Hacker).

BTW my first TC instance was completely frozen (USB stick folder was opened in it) until second one wrote that file... And I can't kill that one (kill reports error 'Can't kill process being terminating'). It seems that TC doesn't tell to copy function that operation is cancelled.

BTW2 when second TC instance closed (that wrote file) I opened the file and it was only 3% completed so TC left the file in bad state...

BTW3 with BTM behavior is the same.

[ghisler(Author)]

I cannot reproduce this, sorry. I guess that Windows was putting a lot of data in write cache, so even when TC requested the abort, it didn't work immediately. I have added some extra code, but it will probably not help in your case.

[MVV]

Today I tried writing 2 GB file to USB stick. At first I stopped copying (at 2-3%), TC stopped it correctly (it took some seconds but then it stopped copy process), but then I tried copying and closing TC, it really didn't close and Process Hacker showed its strong disk write activity for some minutes.

AFAIK Windows flushes cache on file close, so even if it flushes it, it should happen before TC trying to close, TC must not terminate itself until background threads finish because it will destroy objects that background thread may still use. If you use Windows copy function, you should wait until it calls your callback in order to abandon operation.

[ghisler(Author)]

Sorry but I cannot do that. Currently TC sends a WM_SYSCOMMAND/SC_CLOSE to these background windows with a flag set so they don't show the abort confirmation dialog. If TC would wait indefintely, it could hang forever. The user is warned that the background transfers would be cancelled.

[MVV]

Actually TC hangs anyway so waiting is not a biggest problem. The problem is that background transfer is still active (but there is no way to stop it now). You should give threads some time to finish work before you terminate entire process. User won't notice that TC is still waiting if it is hidden, but it will be the correct way. You can wait for e.g. 30 seconds and then terminate.


I can reproduce it on different computers, Win7x64Pro, Win7x64Ent.

Steps:
1. Open new TC with clean INI and locate large file (~2-4 GB).
2. Open USB stick in target panel.
3. F5, Enter, 'Background'.
4. Wait until 1-5% is completed, then close this TC and confirm terminating of background threads.
5. Open Process Explorer of Process Hacker and check that TC is still running. Only one thread left in the process and disk activity may be noticed, no open handles left, and there's no way to terminate it.

And TC closes only when it writes ammount of data matched with file size. But if I open this file, it is full of zero bytes (only few first percents contain data - probably just before TC close moment).

Screenshot (above arrow - after step 2, below arrow - after step 4).

[ghisler(Author)]

I'm sorry but I really cannot see any hangs here, there operation is terminated.

[MVV]

Maybe there is something I can do in order to help you here?

[ghisler(Author)]

Currently I don't see anything you could do. Even with my slowest USB stick, TC closes just fine when you confirm the "Active threads" warning. It takes several seconds here until it disappears, but the process is gone when it does...

[MVV]

It really can take more than minute for large file in my case...
And all this time TC process is in termination state but it continues writing to file. Process can't be killed/suspended/etc, I can't close file handle...
I can live with it but if there is a bug it would be better to find it.

[ghisler(Author)]

What happens when you cancel such a copy operation via the button in the progress dialog? Does TC hang for a minute until it stops copying?

[gdpr deleted 6]

I can confirm the problem with both TC8.50b6 32-bit and 64-bit in Windows 7 Pro x64.

Fresh wincmd.ini has been used.

Using the "Cancel" button in the progress dialog stops the copy action successfully after a small delay of about 1 sec. (which might be very well the time to delete the incomplete file fragment from the stick).

I tested:
- FAT32 USB2.0 stick on both USB3.0 and USB2.0 ports - reproducible.
- NTFS USB2.0 HDD on USB3.0 and USB2.0 ports - not reproducible.
- NTFS RAM disk (removable media type) - not reproducible.

[MVV]

What happens when you cancel such a copy operation via the button in the progress dialog? Does TC hang for a minute until it stops copying?

It cancels it within a few seconds.

I can confirm the problem with both TC8.50b6 32-bit and 64-bit in Windows 7 Pro x64.

Great! My stick also has FAT32 system.

[ghisler(Author)]

It cancels it within a few seconds.

I see - TC waits only half a second after telling the background threads to stop. I don't want to stall TC for several seconds when the user closes it, so I don't currently see a good way to handle this. Maybe I should just close the window and wait while it's hidden for the threads to close, e.g. for max 30 seconds?

[gdpr deleted 6]

I see - TC waits only half a second after telling the background threads to stop. I don't want to stall TC for several seconds when the user closes it, so I don't currently see a good way to handle this. Maybe I should just close the window and wait while it's hidden for the threads to close, e.g. for max 30 seconds?

The approach could be fairly simple: Instead of merely telling the threads to shut down, tell them to do exactly the same as what they do already when you cancel them manually via "X" close button of their respective BG windows. Then wait for them to stop by themselves - or stop them if these are 'general' background worker threads processing queues of different job/tasks.

Yyou would not need to have a separate confirmation dialog from each background thread, since TC already asked the user about "BG operations active. Terminate anyway?"

Of course, i don't know your code base. It could very well be that this seemingly simple idea could have a more substantial impact on your code (i just say "Can-o-worms").

[MVV]

Maybe I should just close the window and wait while it's hidden for the threads to close, e.g. for max 30 seconds?

I fully support such solution, I've told exactly about it:

User won't notice that TC is still waiting if it is hidden, but it will be the correct way.

Of course, i don't know your code base. It could very well be that this seemingly simple idea could have a more substantial impact on your code (i just say "Can-o-worms").

I think the main problem here is Windows API function that calls TC callback function sometimes to report progress, so we need to wait until it will call it again to tell it to cancel operation.