-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. #149
Comments
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. |
Maybe UNC paths ( |
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 |
I still have to set |
|
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 |
Update: version 0.3.0.2 fixes this bug and should now be available in winget. This issue will be closed when the code is ported to v0.4. |
I have just improved this so that it properly stops letting you know that it couldn't extract files with paths that are too long if long file path support is unavailable. This change will be added to v0.4, as I'm not planning on doing any more v0.3.x releases due to that version not having the nearly-instant search and usually-faster package list loading code. This shouldn't be an issue right now though, as the manifest for the unofficial ProtonMail client was either removed or renamed to be shorter and fit within 259 characters. |
It's in v0.4 now. |
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.The text was updated successfully, but these errors were encountered: