I'm not quite sure if this is a bug, but that's for you to decide.
I used TC 8.0b5 x64 to delete about 50 GB of files (lots of directories, thousands of files). As this took quite a time I put the delete action in the background and kept on working.
After a while the system (Phenom x4, 3,2 GHz, 8 GB RAM, Win 7 Home Prem. x64) became sluggish, later almost unusable.
When I tried to find the reason I saw that TC used almost 7 GB of RAM, leaving next to nothing for other programs.
When i killed TC it eventually freed the memory and the system started working normal again.
I deleted the rest of the files using the Windows Explorer without strange effects.
A while later I once again had to delete a certain amount of file s (around 12 GB of data this time). And once again TC started to used abnormal amounts of RAM (upwards of 2 GB).
[TC 8.0b5 x64] high memory usage when deleting files
Moderators: Hacker, petermad, Stefan2, white
Re: [TC 8.0b5 x64] high memory usage when deleting files
Yes, I confirm this behavior too and I believe it is a bug. HolgerK's advice works. Nonetheless this might be fixed.
It's not. Ghisler explained already that it's a problem in Windows itself: Microsoft changed the way files are deleted (now each file is processed in a separate thread; with many files it requires lots of resources). TC now uses VistaDelete=1 by default.muzungu wrote:and I believe it is a bug.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
I guess you mean thisFlint wrote:TC now uses VistaDelete=1 by default.
2ghisler(Author)ghisler(Author) wrote:Therefore the next version of TC will use VistaDelete=1 by default on Windows Vista/7
Actually VistaDelete is deactivated in TC8.0b6.
Do you still consider to change the default to VistaDelete=1?
Regards
Holger
-
ghisler(Author)
- Site Admin
- Posts: 50479
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Actually I disabled VistaDelete=1 because it caused troubles on Windows 8 beta. But this is fixed now, so I will re-enable it.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Hm, seems as if we ignored the potential side effect of changing the default value to VistaDelete=1 in cases where "Ask for confirmation" has been disabled in the recycle bin properties, cf. TC80ß7x32 deletes without inquiry. 
Karl
Karl
Hmmh. Don't know if this side effect is only a move to recycle bin without confirmation (guess some other users would be happy to know a way to disable the delete confirmation in TC) or a really big bug where data are lost by accidentally pressing <del>.
I've read the arguments of JOUBE, but if he wants consistence at any price, why did he disable the delete confirmation of windows, and why is it such a big problem to set VistaDelete back to 0?
On the other side, if i remember well, some users are complaining about a totally unresponsive OS while deleting a huge amount of files (someone might press the reset button in this case and really run into trouble).
Regards
Holger
I've read the arguments of JOUBE, but if he wants consistence at any price, why did he disable the delete confirmation of windows, and why is it such a big problem to set VistaDelete back to 0?
On the other side, if i remember well, some users are complaining about a totally unresponsive OS while deleting a huge amount of files (someone might press the reset button in this case and really run into trouble).
Regards
Holger
Hello, HolgerK.
As explained in that other thread:
The default value of VistaDelete has changed from inactive (0) to active (1).
This change will be effective the moment that you launch T.C. 8.0ß7 for the very first time without the user knowing.
Why?
Pretty simple: Most users will never have bothered to add VistaDelete to their wincmd.ini. So the default value is used. Before updating beta6 to beta7 the default was VistaDelete=0, now it is VistaDelete=1.
Now simply imagine that someone has forgotten that he has disabled the Windows recycle bin confirmation dialogue.
Up to T.C. 8.0ß6 T.C. would ask for confirmation before deleting. With VistaDelete=1 Windows would ask for confirmation had it not been instructed not to do so. Ouch.
In the better case, Windows is still configured to delete to the recycle bin. So chances are good to restore from there.
In the worst case, Windows has been configured to delete directly and not to ask for confirmation. Press DEL in T.C. with VistaDelete=1 and say byebye to your data.
You will be delighted in particular if you pressed DEL on the wrong file(s) or folder(s) by mistake.
The nasty thing is that your foolish recycle bin configuration may hit you right after updating to T.C. 8.0ß7 provided you are on Vista/Win7/Server 2008/Server 2008 R2.
T.C. changes the default value of the delete method it uses on these platforms and thereby loses control over the confirmation dialogue. And all this without telling you beforehand that it is going to do so and without instructing you to (re-)enable the Windows recycle bin confirmation dialogue.
We don't really believe that the majority of users who install a new beta version take the pain of going through the history.txt beforehand. Personally I read it after installing.
This is why in that other thread wrote that my preferred way out of this situation would be to revert back to VistaDelete=0 as the default and a nice and simple tickbox in the configuration box where you can tick or untick [_] VistaDelete (faster on Vista and higher. If you tick VistaDelete, re-enable this bloody recycle bin confirmation dialog to avoid data loss)
I'd rather explain how to activate VistaDelete=1 to another two dozen users who complain about deleting being too slow than being forced to explain that he should have re-activated the recylcle bin confirmation dialog before pressing DEL on the wrong file/folder.
Kind regards,
Karl
As explained in that other thread:
The default value of VistaDelete has changed from inactive (0) to active (1).
This change will be effective the moment that you launch T.C. 8.0ß7 for the very first time without the user knowing.
Why?
Pretty simple: Most users will never have bothered to add VistaDelete to their wincmd.ini. So the default value is used. Before updating beta6 to beta7 the default was VistaDelete=0, now it is VistaDelete=1.
Now simply imagine that someone has forgotten that he has disabled the Windows recycle bin confirmation dialogue.
Up to T.C. 8.0ß6 T.C. would ask for confirmation before deleting. With VistaDelete=1 Windows would ask for confirmation had it not been instructed not to do so. Ouch.
In the better case, Windows is still configured to delete to the recycle bin. So chances are good to restore from there.
In the worst case, Windows has been configured to delete directly and not to ask for confirmation. Press DEL in T.C. with VistaDelete=1 and say byebye to your data.
You will be delighted in particular if you pressed DEL on the wrong file(s) or folder(s) by mistake.
The nasty thing is that your foolish recycle bin configuration may hit you right after updating to T.C. 8.0ß7 provided you are on Vista/Win7/Server 2008/Server 2008 R2.
T.C. changes the default value of the delete method it uses on these platforms and thereby loses control over the confirmation dialogue. And all this without telling you beforehand that it is going to do so and without instructing you to (re-)enable the Windows recycle bin confirmation dialogue.
We don't really believe that the majority of users who install a new beta version take the pain of going through the history.txt beforehand. Personally I read it after installing.
This is why in that other thread wrote that my preferred way out of this situation would be to revert back to VistaDelete=0 as the default and a nice and simple tickbox in the configuration box where you can tick or untick [_] VistaDelete (faster on Vista and higher. If you tick VistaDelete, re-enable this bloody recycle bin confirmation dialog to avoid data loss)
I'd rather explain how to activate VistaDelete=1 to another two dozen users who complain about deleting being too slow than being forced to explain that he should have re-activated the recylcle bin confirmation dialog before pressing DEL on the wrong file/folder.
Kind regards,
Karl
Protect the minorities!HolgerK wrote:Most users will never have bothered to disable the delete confirmation in windows.
Good idea. Anything will be welcome that will make sure automatically using a default value, VistaDelete=1, will not automatically disable the only confirmation dialog left.Only activate Vistadelete automatically under the condition that the delete confirmation is not turned off.
Karl
