-8.51 after update - folder sync RAM and CPU 100% (solved)
Moderators: Hacker, petermad, Stefan2, white
-8.51 after update - folder sync RAM and CPU 100% (solved)
during folder sync (asynchronous) TC is slowing down my computer completely. It needs 100% of both Processors (totalcmd64.exe) and my complete RAM (4GB) during first phase (delete of nonexistend files in target directory). (Options: use Explorer-method)
The following copy action is without problems (50% of CPU)
system WIN7 x64
The following copy action is without problems (50% of CPU)
system WIN7 x64
Last edited by kargol on 2015-06-11, 11:02 UTC, edited 1 time in total.
- ghisler(Author)
- Site Admin
- Posts: 49100
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
This isn't a bug in TC, it's a bug in Windows: It's not possible to delete files from multiple directories to recycle bin with a single function call. TC has to call the function for each directory separately. Unfortunately Windows creates a new thread for each directory, so this can overload the system when deleting files from many directories at the same time.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Maybe TC could serialize deleting - for example something like this:
- set directory change notification,
- start deleting the first directory,
- wait for the notification and check if the directory has been successfully deleted,
- repeat the above for each next directory.
Optionally, TC could delete simultaneously as many directories as available CPUs cores - in this way, deleting shouldn't be slower than the current method, in fact it should be faster by avoiding excessive thread creation.
Regards
- set directory change notification,
- start deleting the first directory,
- wait for the notification and check if the directory has been successfully deleted,
- repeat the above for each next directory.
Optionally, TC could delete simultaneously as many directories as available CPUs cores - in this way, deleting shouldn't be slower than the current method, in fact it should be faster by avoiding excessive thread creation.
Regards
- ghisler(Author)
- Site Admin
- Posts: 49100
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
That's an interesting idea, although it could cause a big slowdown over networks: When I delete a folder on Windows 7, another Windows 7 PC seems to see the change (via FindFirstFile) only about 10 seconds later...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- ghisler(Author)
- Site Admin
- Posts: 49100
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
2MVV
I tried this, but when I put files from different directories in the list, then the ENTIRE directories were deleted - not just the (few) files I put in the list...
I tried this, but when I put files from different directories in the list, then the ENTIRE directories were deleted - not just the (few) files I put in the list...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Checked it, following code deletes only two specified files, even when there are other files and subfolders:
Code: Select all
SHFILEOPSTRUCT fos={0};
fos.wFunc=FO_DELETE;
fos.fFlags=FOF_ALLOWUNDO; // may be commented to delete w/o recycle bin
fos.pFrom=L"D:\\Temp\\shoperation\\0\\test.cpp" L"\0"
L"D:\\Temp\\shoperation\\1\\UpgradeLog.XML" L"\0";
int r=SHFileOperation(&fos);
- ghisler(Author)
- Site Admin
- Posts: 49100
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Maybe they fixed it in the meantime in some service pack or windows update. Since I don't know when they fixed it and how well, I don't want to take the risk.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Maybe there was just a mistake when trying to delete multiple folders with SHFileOperation...?ghisler(Author) wrote:I tried this, but when I put files from different directories in the list, then the ENTIRE directories were deleted - not just the (few) files I put in the list...
There are two important requirements:
1) Names should be fully qualified paths to prevent unexpected results.
2) Each file name is terminated by a single NULL character. The last file name is terminated with a double NULL character ("\0\0") to indicate the end of the buffer.
Can you reproduce the problem again?
- ghisler(Author)
- Site Admin
- Posts: 49100
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Strange, my reply has disappeared. I'm not using SHFileOperation, because it doesn't allow to show my own progress dialog. I'm using the following newer function:
Code: Select all
CoCreateInstance(CLSID_FILEOPERATION,nil,CLSCTX_ALL,IID_IFILEOPERATION,pfo);
pfo.SetOperationFlags(FOF_ALLOWUNDO);
pfo.SetOwnerWindow(FileDlgHandle);
pfo.Advise(opsink,@cookie);
pfo.SetProgressDialog(opprogr);
hr:=SHCreateItemFromParsingName(fullname,nil,IID_ISHELLITEM,psiFrom);
if SUCCEEDED(hr) then
hr:=pfo.DeleteItem(psiFrom,nil);
if SUCCEEDED(hr) then begin
hr:=pfo.PerformOperations;
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com