Crashing when right-clicking on multiple selected files

[vertigo]

Everything kept crashing when searching "P:\*.jpg" and selecting multiple files then right-clicking on them. Tried with xml files and with jpg files elsewhere and it doesn't crash, tried with other file types on P drive and didn't crash, so not sure what triggered it with those specific ones. Got a debug log of it but it lists the search results, which shows all the files, so that's not getting submitted. Can't really provide much other info, so not sure how much help this is, but figured I'd bring it up.

[raccoon]

Under Help -> About Everything, which version are you using?

[therube]

Do you have any content-menu handlers set up that deal with .jpg files?

https://www.nirsoft.net/utils/shexview.html

[vertigo]

1.4.1.965 (x64)

Not that I can tell. I assume they'd be listed as "JPG" or "JPEG" or ".jpg/.jpeg" but I don't see those or anything else that might indicate that I do. Also, as I said, it was only an issue on that drive. I recently did the same on four other drives and another directory and its subdirectories on a fifth drive without any issues; this was the only one that was a problem for some reason. I also tested by just searing "*.jpg" without specifying a drive and it was fine. Maybe there was a corrupt file in the ones that caused the crash.

Edit: I should also add that I ended up just using explorer to search the drive for .jpg's and delete them, which worked flawlessly. I typically use Everything or other software instead of explorer because it's generally a POS. But in this case it had no problems.

[NotNull]

Does (did?) one or more of these files have a very long path and/or filename?
You can test this quickly by adding

path:len:>255

to your search query.
If it shows one ore more files, the answer is yes (and there might be soltions to this issue)

[vertigo]

Probably. As I said, they're gone now, but they were all .jpgs created by media server software, one for each video file, and there are currently 10 video files on that drive that are >255 characters. Furthermore, selecting and right-clicking on those causes Everything to crash in the same way, so I'd say it's a good bet that's the problem.

[NotNull]

This can be caused by a shell extension that doesn't handle really long path names.
Please enable shell max path:

• In Everything, type in the following search and press ENTER:

  Code: Select all

  /shell_max_path=1

• If successful, you should see shell_max_path=1 in the status bar for a few seconds.

Is the issue gone after this?

[vertigo]

Showed up in the status bar, but Everything still crashed.

As a side note, every time it crashes the next startup takes a while before it's ready because it has to rebuild the index, which shouldn't be necessary.

[monke]

Just encountered the same issue on 1.5a.

image.png

Interestingly, Everything froze despite taking up less than 1 GB of memory - with many gigs to spare.

Edit: it just unfroze, after ~10mins of hanging... No right-click menu though (probably got auto-dismissed from having clicked elsewhere), so I right-clicked and... it froze again

I did notice a brief "Building of the file list" progress bar in the status bar that completed in a couple seconds before the window froze.

Edit 2: Setting

Code: Select all

context_menu_shell_extensions

to "false" does fix the freezing. ShellExView shows the following non-M$ extensions:

7-Zip Shell Extension
7-Zip Shell Extension
HardLink Context Menu
HardLink Context Menu
HardLink Context Menu
HardLink Copyhook
HardLink IconOverlay Hardlink
HardLink IconOverlay Junction
HardLink IconOverlay SymbolicLink
HardLink PropertySheetPage
LockHunterShellExtensionHandler Class
PDF Preview Handler
RecuvaShellExt Class
SumatraPDF Preview (*.cb7)
SumatraPDF Preview (*.cb7)
SumatraPDF Preview (*.djvu)
SumatraPDF Preview (*.djvu)
SumatraPDF Preview (*.epub)
SumatraPDF Preview (*.epub)
SumatraPDF Preview (*.fb2)
SumatraPDF Preview (*.fb2)
SumatraPDF Preview (*.mobi)
SumatraPDF Preview (*.mobi)
SumatraPDF Preview (*.pdf)
SumatraPDF Preview (*.pdf)
SumatraPDF Preview (*.tga)
SumatraPDF Preview (*.tga)
SumatraPDF Preview (*.xps)
SumatraPDF Preview (*.xps)

PDF Preview Handler belongs to Edge, so unsure why it was listed as non-M$.

I've disabled every non-M$ extension, but even that didn't fix the freezing.

One thing I've noticed is the fewer files I select the shorter the freezing time. For example, 15000 selected items gets the window frozen for only ~30 seconds.

[void]

Showing the context menu for 1000+ items will take a long time.

Everything calls the OS to get the context menu.
The OS wants a list of PIDLs (items)

To do this, Everything converts filenames to PIDLs.
This is slow and progress is shown in the status bar.

The OS call to get the context menu with 1000+ PIDLs is slow.
There's no progress feedback, it's done on the UI thread and it cannot be cancelled.
I'll look into moving this to another process in a future version of Everything.

For now, avoid right clicking 1000+ items unless you really want the OS context menu.
-or-
Use the main File menu to avoid the slow OS call to get the context menu.

[therube]

Wouldn't toggling (some of / particular) .pidl about:config settings help to alleviate that delay?
Wouldn't you then be able to right-click ~1 million files, in < 30 seconds. (I can.)

; pidl ARE need (if you're selecting / dragging LOTS of items)
context_menu_simple_pidl=1
drag_drop_simple_pidl=1

[monke]

Use the main File menu to avoid the slow OS call to get the context menu.

I did not realize that was an option. Very handy. I wish the Send-To submenu was accessible from the File menu, but "Copy full path"/"Export" will absolutely do for now for my use-case.

Wouldn't toggling (some of / particular) .pidl about:config settings help to alleviate that delay?
Wouldn't you then be able to right-click ~1 million files, in < 30 seconds. (I can.)

Huge if true. But I can't seem to locate these about:config settings that let you toggle particular .pidls. Is this something you do outside of Everything?

; pidl ARE need (if you're selecting / dragging LOTS of items)
context_menu_simple_pidl=1
drag_drop_simple_pidl=1

I set the following:

Code: Select all

context_menu_focus_simple_pidl=1
context_menu_simple_pidl=1
drag_drop_simple_pidl=1

Can't say this gave me a drastic speedup... The window still freezes. It might be unfreezing a little quicker now? Unsure.

Appreciate the help both you guys. Useful stuff I had no idea about.

[NotNull]

- Everything calls the OS to get the context menu.
- The OS wants a list of PIDLs (items)
- To do this, Everything converts filenames to PIDLs.
(The OS call to get the context menu with 1000+ PIDLs is slow)

Without knowing the exact inner workings of calling the OS to get a contexct menu, could the following "generate" the same context menu?
(Example: 10000 .txt files and 5000 .ini files)
- Everything runs a "distinct:extension" on the selection of 10000 .txt files and 5000 .ini files to de-duplicate extensions (instead of 15000 files, only two would be left: one .ini and one .txt).
- Everything looks up the PIDLs of these two remaining files.
- Everything calls the OS to get the context menu of these two files.


EDIT:
Never mind; there is more context to the context menu than just the file extension, like it's location and in more exotic cases other file properties.
On the other hand, a "QuickContextMenu" option (that might cut some exotic corners) still can be useful.

[void]

Without knowing the exact inner workings of calling the OS to get a contexct menu, could the following "generate" the same context menu?

This is what the OS calls IQueryAssociations.
Everything just builds these from the extension of the focused file.
So if you right click an mp3 file you get a audio-file style context menu.

The OS still requires a list of PIDLs to build the context menu.
I can't fake a small list then change it later once something gets invoked.



Enabling context_menu_simple_pidl will help with the performance of building the PIDL list.
But doesn't help the performance of the OS building the context menu.

context_menu_simple_pidl

[NotNull]

Well, it was worth a shot ..
(not that I ever ran into this, other than for testing purposes)

Thanks for the explanation!