Using Everything for large file operations

[Shooter3k]

When doing large file operations, like say if I right click on 30 folders and pick 'delete', would it be possible to run that in a separate thread somehow while windows works on the "discovered" phase and deleting the files?

Right now, it locks/blocks Everything from doing anything while Windows does the "Discovered"

[void]

I will consider an option to run file operations in a separate thread.
Thank you for the suggestion.

For now, file operations run in the UI thread.

To create a new window when Everything is busy:

• Middle click the Everything taskbar button
  -or-
• Right click the Everything tray icon and click New Window.

[therube]

But... aren't ALL windows going to be busy?

Or is that ALL existing windows will be busy?
That's all I've ever seen.
(All existing windows are busy. I've never attempted to open a new window during a busy time.)

Right click the Everything tray icon and click New Window.

Likewise a taskbar icon.
(In Win7, that would be Shift+Right-click | Everything.)
(And possibly in Win10 too, if you've reversed the meaning of right-click of a taskbar icon.)

[void]

The file operation dialog is "modal dialog" in Everything.
The main window will be disabled until the file operation completes.

The tray icon will still be responsive and you can make a new window.
You can also make a new window by middle-clicking the Everything taskbar button.

Or is that ALL existing windows will be busy?

All windows will be busy if you perform an action on the Everything database while it is already busy.
Such as performing a lengthy search and trying to click in the result list.
Everything will block until the search completes. All windows will appear busy.

The file operation dialog doesn't use the Everything database so this blocking should not occur.

[therube]

The file operation dialog doesn't use the Everything database so this blocking should not occur.

If you select a number of files, say a couple GB, Copy, then Paste them elsewhere (all from within Everything), is that considered a "file operation"? Cause that certainly blocks me, until the copy completes.

(Now, during that time, I was able to open a new window [from Taskbar], but as soon as it opened, it went busy [was blocked].)

(With a smaller copy set, smaller size, the same occurs, but it is relatively brief, so may not be particularly noticeable.)

[void]

If you select a number of files, say a couple GB, Copy, then Paste them elsewhere (all from within Everything), is that considered a "file operation"?

Pasting to a single folder: = No.
Everything will use the paste verb.

Everything will also cut and copy files with the cut/copy verb.

So essentially, the cut/copy and paste is done by the system.
The system shouldn't block when pasting, the pasting is done asynchronously (without blocking), so I'm not sure what is going on there.
It could just be the system freezing while the copy takes place. Are you copying to a spinning disk?

The system might paste synchronously (block on paste) if the cut/copied items do not support asynchronous file operations.
How are you cutting/copying the items?
-Have you enabled simple PIDLs, that would likely cause this. (Tools -> Options -> Advanced -> context_menu_focus_simple_pidl and context_menu_simple_pidl)



If you paste to multiple folders or paste to folders with a very long filename, then Yes, Everything will use IFileOperation.
IFileOperation will also paste asynchronously. (without blocking)

(Now, during that time, I was able to open a new window [from Taskbar], but as soon as it opened, it went busy [was blocked].)

To me, if the paste was blocking, you wouldn't be able to open a new window at all and this would indicate the copying/pasting is just slowing the system.

[therube]

Have you enabled simple PIDLs, that would likely cause this.

That rings a bell (Context-menu slow).
That I did this cause I'm apt to right-click &/or drag large numbers of files into other programs (which was otherwise [relatively] slow).
[I'll have to check.]

If that's the issue, I'll just live with it.


(And yes, my drives are spinners.
Though with the faster ones, I get more throughput then to my USB 2.0 attached SSD.)

[therube]

Code: Select all

context_menu_simple_pidl=1
context_menu_focus_simple_pidl=0
drag_drop_simple_pidl=1

context_menu_simple_pidl=1
- unsure about this one?
=0, you get the "Building" dialog, =1 you do not, though times appear close ?
(didn't see times in debug console, at least not a singular, "oh, it took so long to complete"...)

maybe a New window did not open?
maybe i (assumed) a new window opened, but i was really looking at an existing window
where the fields/results were simply "blank" due to blocking?
no, probably not.

pidl=1, during copy/paste, i'm blocked, center-click taskbar icon DOES open new window,
but it also is blocked
pidl=0, during copy/paste, ditto - but, maybe ? there were times when new window didn't
open till unblocked, not sure?

(my Tray icon is typically hidden, so i'm not apt to use that)

- changes to context_menu_simple_pidl do not seem to be making a difference one way or the other (on my end)


drag_drop_simple_pidl=1
- makes a world of difference (speed wise), so i'm keeping it enabled, regardless

[void]

It's likely a USB bandwidth issue.

context_menu_simple_pidl=1
- unsure about this one?

context_menu_focus_simple_pidl == use a simple pidl for all focused item.
context_menu_simple_pidl == use a simple pidl for all other items.

=0, you get the "Building" dialog, =1 you do not, though times appear close ?
(didn't see times in debug console, at least not a singular, "oh, it took so long to complete"...)

Building normal pidls will take a while.
Building simple pidls should be pretty quick.
Both can show a "Building" progress bar.
The progress bar might not even appear for simple PIDLs. -Everything can build millions of simple PIDLs a second.

Building the IContextMenu to invoke the Cut/Copy/Paste verb still takes a long time.
I don't show a progress bar here.
The system has all the information, but it's just slow..

pidl=1, during copy/paste, i'm blocked, center-click taskbar icon DOES open new window,
but it also is blocked
pidl=0, during copy/paste, ditto - but, maybe ? there were times when new window didn't
open till unblocked, not sure?

- changes to context_menu_simple_pidl do not seem to be making a difference one way or the other (on my end)

I'm seeing similar results without the blocking.

My IDataObjectAsyncCapability implementation is not very good.
I will improve this for the next alpha update.
This could be causing troubles if you cut many items from Everything from different locations.

drag_drop_simple_pidl=1
- makes a world of difference (speed wise), so i'm keeping it enabled, regardless

Most drop handlers don't need normal PIDLs, so this should work fine.

[void]

Everything 1.5.0.1400a improves the IDataObjectAsyncCapability implementation.

I doubt this will help... just making a note here.