Major known issue: Apparently the unofficial ProtonMail desktop client's locale manifest's resulting filepath when extracted is too long for Windows without using the long file paths Registry key.

[DrewNaylor]

Here's a screenshot:

I figured out it's probably too long for Windows by trying to rename its installer file to the locale file, and I couldn't put the entire extension in, so it just ended up as a .y file. Perhaps there should be a way to handle these situations by deferring to winget for package information not available in the database file. Unfortunately, this is a problem in v0.3.0.1, and a fix won't be available immediately as I want to take a break for now.

(Edit: I'm pretty sure it is a max path limitation, as the path is 259 characters and the default limit without opting into extended paths is 260, and I'm sure .NET Framework adds a null-terminator to the end: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

What I can do is let the user choose whether to ignore manifests that are too long, get their info from winget, or use the long file paths by changing the registry.)

See also #148 as that one is somewhat related due to this one manifest causing the rest to not extract or load.

For now you can right-click a package and select Show in winget... to get package details for unloaded manifests.

[DrewNaylor]

I'll have to create a CLI app that can be run to set the long file path support in the Registry. There will be the three radio buttons, and selecting the one to use long file paths will pop up a message box asking if the user wants to turn on long file path support, so they don't have to use a button for it. Clicking "No" will go back to their saved setting, but clicking "yes" will open UAC for running the CLI app to set long file path support. If long file path support is currently on in the Registry when the Options window is open, a button to turn it off will be enabled for people to use if they want to. Clicking the button will also reset to always asking the user. A messagebox will also let the user know that's going to happen, with an option to continue or not.

[DrewNaylor]

Maybe UNC paths (\\?\C:\ for example) would be another option, but that requires more work and testing from me.

[SvenErik1968]

I have the long paths settings enabled in the registry (on Win11, settings date back to from before I ugraded from Win10), but I still get this error:

Maybe another possible solution would be to allow a manually set temp folder? I still use a C:\Temp folder; if I could use that, it would reduce the length of the temp-path (C:\Users\Sven-Erik\AppData\Local\winget-frontends\source\winget-pkgs\temp\) from, in my case, 74 to 8 chars.

[DrewNaylor]

I still have to set longPathAware in the manifest even if it's set in the Registry, which is probably why you're still running into it. It's good to know there are other manifests with the issue. Allowing a custom manifest directory root is a good idea, I'll add that option in the next version (edit: well, next "major" version, that being v0.4). Thank you for suggesting it.

[4-FLOSS-Free-Libre-Open-Source-Software]

---------------------------
Extracting manifests
---------------------------
 "C:\Users\Sven-Erik\AppData\Local\winget-frontends\source\winget-pkgs\temp\winget-pkgs-master\winget-pkgs-master\manifests\u\unofficial-protonmail-desktop\unofficial-protonmail-desktop\1.2.1\unofficial-protonmail-desktop.unofficial-protonmail-desktop.locale.en-US.yaml" 
---------------------------
OK   
---------------------------

[DrewNaylor]

For now, I'll just ask people to use .reg files to enable or disable LongPathsEnabled since it's easier to do this quickly than it is to add more stuff into the Options window. I've also added long file path awareness to the manifest, so it won't break anymore if LongPathsEnabled is 1. Both of these changes will be added to main/v0.4 soon, but for now they're just on the v0.3.0.1-backports-from-v0.4 branch and will first be available in v0.3.0.2.