Icons (.LNK) - path:len:>259 - Version 1.4.1.948 (x64) & (x86)

[tuska]

Since version 1.4.1.948 (x64 & x86), shortcut icons to Outlook messages are no longer displayed.

2019-08-19_Icons_Version 1.4.1.948 (x64).png (29.38 KiB) Viewed 13487 times

Could you please look into the matter.
Thank you!

[therube]

(I'll note that on XP, seems that ".lnk" icon overlay has been missing on LFN for some time now - at least since .941, maybe forever?, & is likewise missing in .948.)

shortcut icons to Outlook messages

I'll take it that the shortcut icon is missing from all files (regardless of type) where path:len:>259 ?

[tuska]

shortcut icons to Outlook messages

I'll take it that the shortcut icon is missing from all files (regardless of type) where path:len:>259 ?

Yes, it looks the same to me - but I only tested these few file types additionally: .txt, .png, .ahk

In version 1.4.1.947 (x64) the shortcut icons for the above file types were still displayed correctly.

-------------------------
Windows 10 Pro (x64) Version 1903 (OS Build 18362.295)

[void]

Version 948 removes support for gathering icons in paths longer than or equal to 260 characters (MAX_PATH)

Everything uses SHGetFileInfo to gather icon information.
This API call, and other shell calls have a limit of 260 characters (or 259 characters and a null terminator).
Everything has previously being ignoring this limit and passing paths longer than 260 characters, which works fine with stock Windows XP,7 and 10.
However, some shell extensions crash when passed a path longer than or equal to 260 characters.

I've experimented with converting long paths to short paths names, eg:
c:\users\user\desktop\a really long path 0123456789012345678901234567890123456789012345678901234567890123456789...\foobar.ico
to:
c:\users\user\desktop\areal~1\foobar.ico

However, this still crashes shell extensions.
The same also applies with using ITEMIDLISTs that resolve to paths longer than or equal to 260 characters.


These crashes also occur in Windows Explorer. However, they are more likely to occur in Everything as you would have to browse to the long path in Windows Explorer.

I've added an ini setting shell_max_path for the next update, when set to 0 Everything will bypass this shell API limit of 260 characters at the risk of crashing Everything.

I'm leaning towards having this enabled by default (set to 1) which will enforce the 260 character limit. I still have some more testing to do before a nightly update..
What are your thoughts? -should I obey the API limits? should I allow long paths anyway at the risk of shell extensions crashing?

[horst.epp]

...
I've added a ini setting shell_max_path for the next update, when set to 0 Everything will bypass this shell API limit of 260 characters at the risk of crashing Everything.

I'm leaning towards having this enabled by default (set to 1) which will enforce the 260 character limit. I still have some more testing to do before a nightly update..
What are your thoughts? -should I follow the obey the API limits? should I allow long paths anyway at the risk of shell extensions crashing?

I think the default of setting shell_max_path to 1 is the best solution for the casual user
who isn't willing or able to debug shell extensions.
Any other can set it to 0 and get what they want.

[therube]

Default 1.
If a user wants to change...

[tuska]

What are your thoughts?

1. In my opinion, an .ini setting is very welcome in order to be able to control the behaviour of the limit of 260 characters.
2. As a user who has no crashes for a long time I would prefer the setting: shell_max_path=0 as default.
    Furthermore, it is not necessary for such users to make an explicit setting in Everything,
    i.e. to override the default setting just to get a view that was already there in the previous version.
3. I think you should allow long paths anyway at the risk of shell extensions crashing
    because faulty shell extensions are not a bug of Everything.

Ultimately, it's likely to be a balancing decision:
- how many crash reports are already there/are to be expected?
- how many users would miss then the right icon at shell_max_path=1?
- how many users would have to enter the new setting shell_max_path=0 themselves to get the display as before
  or do all those concerned then know that they can/must carry out a recording themselves?

[froggie]

I would think that defaulting to the "no crash" option would be best. A crash would leave most users clueless and result in either a support request here or dissatisfaction with Everything. Users may well be unaware of having very long paths and It is unlikely that they would look for an ini option as a solution to a crash.

[NotNull]

In the series "One idiot can ask more questions than ten wise men can answer." a new episode:

So, a lot of Windows API's do not support fully qualified filenames (drive + path + filename + extension) longer than 259 characters.
You can 'cheat' with the icons for long paths without getting into trouble and you can 'cheat' with building the context menu for most shell extensions, but not all.
Some 'idiot' questions:

• Are the two (file icons and shell extnsions) related somehow?
• Will the context menu be shown for pathlengths > 259?
• Do you switch to win32 namespace for these paths (\\?\c:\long\path vs. old c:\long\path)
  (Not that that will help enough as that is what Explorer does and that crashes too)
• As the context menu is build by Everything and consists of an Everything-part (Open ... Set Run Count) and a Windows part (the part that you would see in Explorer), wouldn't it be possible to show just the Everything-part PLUS an extra dummy entry "Path too long for context menu" with the default warning icon. And skip the 'Windows-part' altogether?
  The status bar could show more information / instructions how to bypass that

Maybe I should have tested 1.4.1.948 first ....

[void]

(I'll note that on XP, seems that ".lnk" icon overlay has been missing on LFN for some time now - at least since .941, maybe forever?, & is likewise missing in .948.)

Everything uses SHGetFileInfo to get the overlay icon index. This has the 259 character limitation.

3. I think you should allow long paths anyway at the risk of shell extensions crashing
because faulty shell extensions are not a bug of Everything.

This is a bug in Everything, since Everything is ignoring the MAX_PATH limitation with shell calls.
The SHGetFileInfo implicitly states a limit of 260 characters (including null terminator). Some shell extensions expect this limitation as per the API spec and crash when longer paths are passed.

* Are the two (file icons and shell extensions) related somehow?

Yes, SHGetFileInfo will call the associated IExtractIcon interface (possibly implemented by a shell extension or handled by Windows).

Will the context menu be shown for pathlengths > 259?

For now, always. For the next major release, there might be an option to disable context menus for really long paths, as these too will crash some shell extensions.

* Do you switch to win32 namespace for these paths (\\?\c:\long\path vs. old c:\long\path)

\\?\ paths do not work with the shell, only the base windows API. I've tried shortpaths (eg: C:\longpa~1\... ) and ITEMIDLIST (which is the Windows shell internal path structure) and both still crash shell extensions.

* As the context menu is build by Everything and consists of an Everything-part (Open ... Set Run Count) and a Windows part (the part that you would see in Explorer), wouldn't it be possible to show just the Everything-part PLUS an extra dummy entry "Path too long for context menu" with the default warning icon. And skip the 'Windows-part' altogether?

That might work, a once off "do you want to show really long paths, thumbnails / icons?"
I've also thought about setting a dirty flag when calling the shell, clearing this flag when the call is successful, so I can can detect if the shell crashed the next time Everything is started, perhaps I can notify the user in this case, with the option to enable shell_max_path..



Like Windows Explorer, Everything 1.4.1.949 now bypasses the 259 character limit (MAX_PATH) by default.

If you have a shell extension causing Everything to crash, you'll need to enforce the max_path limit with the shell_max_path ini option:
To enforce the max_path limit:

• In Everything , type in the following search and press ENTER:
  /shell_max_path=1

[tuska]

Thanks for fixing the bug in version 1.4.1.949!
Tested with Windows 10 Pro (x64) Version 1903 (OS Build 18362.295)