XYPlorer hang on file deletion

[TheQwerty]

Interesting result! But note that it's not XY scanning the bin, it's the Shell!

XY calls the shell, so as far as a user is concerned it is XY.

As I said before, XY is just sitting there and waits for the Shell to return.

And that's the problem...
In Windows Explorer the operation is modeless all this enumerating is happening in a background thread and the user can continue to work.

In XY it's blocking, so the user must wait for the shell to finish before anything can be done, regardless of the Progress Dialog Modeless setting.

It appears that WE uses 2 threads (both starting in SHLWAPI.dll) to perform the request, presumably 1 handles the delete/progress and the other does the enumerating. XY only spawns 1.

And there must be another factor. I'm on XP with 6000+ items in my bin and there's no delay at all, nada!

It's more dependent on the number of folders and subfolders, watch it in ProcMon - it walks the tree of the recycle bin enumerating the deleted tree(s).

Using this as a test (after generating 100 empty text files obviously):

Code: Select all

::$i=0;$result="";while($i<100){$i++;$start="<date>";Delete(1,0, ":list");$result="$result<crlf>$i - " . DateDiff("$start",,"s");}Text($result);

With 6000 empty text files in the recycle bin the time per delete was between 0 and 3 seconds, with an average of 0.22. Certainly close enough to nada.

With a recycle bin containing 1 item a folder (DelRoot), whose content is structured as "DelRoot\0\1\2\3\4\5\6\7\8\9\" and each level also contains 500 files, thus 5500 files in 11 nested folders, the time per delete was 3 to 13 seconds with an average of 3.69.

The more folders you delete the worse it gets.
With 6326 objects (which is actually 51419 items, sorry I didn't track the folders/files): average 11 seconds, ranging from 7-38. That's XY blocking (and as far as the user cares hanging) for 7 to 38 seconds to delete a single empty file!


Obviously I can't give you a good comparison in WE for the same scenarios, but it doesn't matter because I'm always able to continue working. As far as the user is concerned it could take two days to enumerate the recycle bin, but the file is deleted and they are on to the next task much quicker.

[admin]

Interesting result! But note that it's not XY scanning the bin, it's the Shell!

XY calls the shell, so as far as a user is concerned it is XY.

As I said before, XY is just sitting there and waits for the Shell to return.

And that's the problem...
In Windows Explorer the operation is modeless all this enumerating is happening in a background thread and the user can continue to work.

In XY it's blocking, so the user must wait for the shell to finish before anything can be done, regardless of the Progress Dialog Modeless setting.

It appears that WE uses 2 threads (both starting in SHLWAPI.dll) to perform the request, presumably 1 handles the delete/progress and the other does the enumerating. XY only spawns 1.. ...

I see, and thanks for the testing! I'll see what I can do...
Any idea why this enumerating is happening?

[admin]

With a recycle bin containing 1 item a folder (DelRoot), whose content is structured as "DelRoot\0\1\2\3\4\5\6\7\8\9\" and each level also contains 500 files, thus 5500 files in 11 nested folders, the time per delete was 3 to 13 seconds with an average of 3.69.

I added such a folder to my recycle bin of 6000+ items and nothing changed for me. Deletion time: nada (< 0.1 sec)!

[carmenm]

I tested it again this morning and it s really related to the recycle bin here

[admin]

I tested it again this morning and it s really related to the recycle bin here

Maybe a virus scanner in the background?

[carmenm]

Already tested without the virus scanner. it s not the reason

[TheQwerty]

I added such a folder to my recycle bin of 6000+ items and nothing changed for me. Deletion time: nada (< 0.1 sec)!

Can you take a look in Process Monitor and see if you see it enumerating the recycle bin at least? (I have no idea what or why it's doing this.)

My only remaining XP machine is my work laptop, so there's quite a lot in the environment that may be causing it if it's not actually XY/Windows (SEP 11, LANDesk, Tortoise* extensions). That also means I can't, and mostly am not willing to, do a lot of disabling and uninstalling.

I haven't experienced it on my machine at home, but that's Vista and there's a huge leap in specs between it and the laptop. I'll try to take a look in Process Monitor to see if it at least appears similar.

Maybe I can reproduce this in a VM later...

[admin]

I added such a folder to my recycle bin of 6000+ items and nothing changed for me. Deletion time: nada (< 0.1 sec)!

Can you take a look in Process Monitor and see if you see it enumerating the recycle bin at least? (I have no idea what or why it's doing this.)

My only remaining XP machine is my work laptop, so there's quite a lot in the environment that may be causing it if it's not actually XY/Windows (SEP 11, LANDesk, Tortoise* extensions). That also means I can't, and mostly am not willing to, do a lot of disabling and uninstalling.

I haven't experienced it on my machine at home, but that's Vista and there's a huge leap in specs between it and the laptop. I'll try to take a look in Process Monitor to see if it at least appears similar.

Maybe I can reproduce this in a VM later...

Which Process Monitor do you mean?

When I delete a file I can in fact see lots of directory action (about 2,500 actions) within recycle bin in SysInternals's File Mon. But it's totally fast, takes about 80 millisecs.

[TheQwerty]

Which Process Monitor do you mean?

SysInternals', A.K.A. The one that replaced File/Reg-Mon.

[jacky]

I added such a folder to my recycle bin of 6000+ items and nothing changed for me. Deletion time: nada (< 0.1 sec)!

Can you take a look in Process Monitor and see if you see it enumerating the recycle bin at least? (I have no idea what or why it's doing this.)

FYI I just tried, so I created myself a "DelRoot\0\1\2\3\4\5\6\7\8\9\" with 500 empty files in each folder, then I send DelRoot to the bin. Now removing a file is still as fast as ever, and using ProcMon I can see XY enumerating the bin, listing the 500 files in each of the 11 folders in the bin, but as for Don it all happens within the same second for me.
Of course I just used the bin so I might be tempted to say that might be why, except that if it is always slow for you guys, even after you just did it once/used the bin, then there must be some other factor that slows things down... (I'm XP SP2 btw)

[TheQwerty]

...except that if it is always slow for you guys, even after you just did it once/used the bin, then there must be some other factor that slows things down... (I'm XP SP2 btw)

I can't say it's always been as slow as I've described here. There's always been a slight pause that has annoyed me, but that's even in WE so I chalked it up to Windows.

But then as I mentioned I typically erase my recycle bin every Monday, so it doesn't grow as ridiculous as some of my examples. It's a valid point because I don't know what the average contents of the recycle bin is like, I doubt there's often 11 nested folders with 500 files each, but I'm sure there's some users who never empty the thing which makes it seem not so ridiculous. :/


I'd agree it's probably some Explorer extension or other software that's slowing it down for carmenm and I, but there's no way I'm going to (nor could I in some cases) do the disabling/uninstalling to determine which, and I don't see anything in ProcMon that points to another culprit.


So on the assumption that it's not XY and (maybe) not Microsoft... Process Explorer shows these programs have DLLs in XY's address space:
Tortoise* (CVS, Git, Hg, SVN, or the common Overlays)
Symantec Endpoint Protection 11
ScriptLogic/Desktop Authority
Autodesk DWF/Express Viewer
Dell Quickset
Jungle Disk
WindowSpace

[admin]

So on the assumption that it's not XY and (maybe) not Microsoft... Process Explorer shows these programs have DLLs in XY's address space:
Tortoise* (CVS, Git, Hg, SVN, or the common Overlays)
Symantec Endpoint Protection 11
ScriptLogic/Desktop Authority
Autodesk DWF/Express Viewer
Dell Quickset
Jungle Disk
WindowSpace

I have none of these, so they are not excused yet.

Of course, even if we find the culprit, I still have to fix it here (by spawning an extra thread probably). It's just more fun to fix something when you can actually see it.

[carmenm]

I already tested without tortoise process or antivirus(you can do it easily by killing the process and do the action without changing dir) and i dont have the other processes.

[Plastic]

Hello,

Just to say I experienced this hang again and saw the thread had been updated.

As stated in my previous post, I also have Symantec Antivirus and TortoiseSVN, so I would think one of them is the culprit
I also never emptied my Recycle Bin, and had nearly 4Go with deeply nested trees. I emptied it and so far it seems the problem is gone!

I already have set Tortoise to disable status cache, so it's not even running anymore
I can't test without antivirus because i don't have admin rights

[KyferEz]

From my experiences with Norton products on hundreds of computers throughout the last 10 years (and it's gotten worse, not better), I'm willing to bet money it's related to Norton AV. And no, you cannot kill Norton's processes to stop it. It has apps, services, and drivers installed and running that must be removed, as all AV programs do. You first have to uninstall Norton, then run Sysinternal's Autoruns and kill the rest of the Norton autoloading crap because it won't fully uninstall itself. Then, and only then, can you say it's not your AV.