XYplorer Beta Club

Whenever I do a move or delete of folders on the same drive in XYplorer, that Windows 10 progress box appears with the green bar. And it's slow to disappear! Bogs down my work flow. I don't recall this being a problem in Win 7. Is there anyway to suppress that popup and speed up the operation? Most of the time, I am doing these operations on portable USB 3 drives, connected to USB 3 ports.

It's particularly annoying since the deletes and intra-drive moves don't involve any significant data transfer. The boxes are always saying "Calculating...". I looked in the File Explorer Folder Options for a setting but didn't see any and nothing found by googling. I have everything checked off for indexing, this drive included, so don't think it's that. XYplorer CPU runs over 10% while this calculating is going on.

IS ANYBODY ELSE SEEING THIS?

The progress box does not make anything slower. It appears to entertain you while something slow is going on.

Now why is your delete so slow? Most probably because your Recycle Bin is REALLY FULL. Open it and remove some stuff. For example the stuff you deleted more than 10 years ago...

admin wrote:The progress box does not make anything slower. It appears to entertain you while something slow is going on.
Now why is your delete so slow? Most probably because your Recycle Bin is REALLY FULL. Open it and remove some stuff. For example the stuff you deleted more than 10 years ago...

I always have the Recycle Bin disabled on all my external drives. and double-checked with the drives in question. Nevertheless, I tried emptying the Recycle Bin but the problem remains. However, I did notice that I no longer had the intra-drive move and delete operations checked in the ApplyTo settings for Backgrounded Operations. So I turned those back on, and while the progress popup still hangs around, it's not blocking me from doing other stuff. I guess that was really the problem.

Still strange why (permanent) delete should take so long. It's only some changes in the MFT after all.

admin wrote:Still strange why (permanent) delete should take so long. It's only some changes in the MFT after all.

Yes, and intra-drive moves should just involve updating directory entries.

But now another problem: With the intra-drive moves backgrounded, I no longer see dragged folders appear under the parent folder in the Mini Tree, even though I am dragging and dropping them directly onto the parent folder in the Mini Tree. And that's also when there are no other background tasks currently being processed. Meanwhile I DO see the subfolder appear when I drag the same folder in from other applications (typically Everywhere.exe).

Now I understand why this is happening and why it's not really inconsistent behavior -- you don't want things popping up from queued backgrounded operations unrelated to what you are doing at the moment. BUT I suggest, that if the background queue is empty, and your current folder drag is now putting the only runnable operation on the queue, then might not an exception be made and somehow notify the Mini Tree to show the resulting subfolder?

[Using 17.10.0000]

Hmm, works here. Always. Whether backgrounded or not.

Are you maybe using a locked mini tree?

admin wrote:Hmm, works here. Always. Whether backgrounded or not.
Are you maybe using a locked mini tree?

No, the Mini Tree is definitely not locked. Here's a protocol that produces the problem for me when I run XYplorer with /fresh.

1. Run XYplorer /fresh. (Using 17.10.0000)
2. Enable Background Processing, but leave Intra-volume moves UNCHECKED in ApplyTo settings. That's the initial default.
3. Turn on Mini Tree
4. Navigate to a folder somewhere in the tree, say X. Leave it unexpanded.
5. In the list on the right, navigate to some other folder Y elsewhere on the drive, but not under X.
6. Drag the folder Y from the list onto X in the tree on the left. Y now appears as a subfolder of X in the tree.
7. Undo the move. Y no longer appears under X but it is now visible in its location elsewhere in the tree.
8. Now CHECK ON Intra-volume moves in BP.
9. Repeat step 5,6. Now, Y does NOT appear under X, though X appears with a + to indicate its presence. But note the tree still updates to no longer show Y in its original location.
10. Undo the move again. Y appears in the tree again in its original location.
11. Turn CHECK OFF Intra-volume moves in BP and repeat steps 5,6. Once again, Y will appear under X.

Confirmed. Fixed. Coming. Thanks!

I tried the fix in v17.10.0002. Dragging from the list onto the mini tree now makes the subfolder appear. But, dragging from elsewhere in the mini tree, onto another folder in the mini tree still does not -- the tree is updated to remove the moved folder, but not to make it appear under the target folder.

Confirmed. I try something better.

admin wrote:Confirmed. I try something better.

The 2nd fix in v17.10.0003 seems to be working. Thanks!

admin wrote:Still strange why (permanent) delete should take so long. It's only some changes in the MFT after all.

Incidentally, I just did another large delete that caused the Progress Box to hang around for over 3 minutes while XYcopy chewed up 13% CPU. There were over 1500 folders & subfolders and all the folders were empty. I ran the Sysinternals ProcMon utility and found a clue: XYcopy was reading one or more files in %appdata%\Roaming\Microsoft\Windows\Recent\AutomaticDestinations. So it would seem that all the delay is involved with updating the Windows 10 recent file jump lists. I could turn off recent items using the Local Group Policy Editor (Win 10 Pro), but don't think I'll do that.

Aha, interesting! So that's (jump lists) one of the things that come with a price.

Note that "Custom Delete" is on my list. This will be a much faster delete: no recycle bin, no updating jump lists, just a raw kill.

Something else: When creating a folder in the list, with Ctrl-N, the new folder now appears in the Mini Tree. Before this, I had to do Ctrl-Shift-N (Create Subfolder Here) to get it to appear (followed by navigating back up to the parent directory). This is a welcome change, intended or not. It's an issue I first raised over 6 years ago, but I ended up having to use Ctrl-Shift-N.