Nightly build fails to save files with long paths on Windows

[yuhoocom]

There appears to be a regression in the nightly builds regarding long path support on Windows. The latest nightly builds are unable to save files to paths exceeding a certain character limit (around 113 characters in my tests), even when long path support is enabled in the Windows Registry.

This functionality works perfectly in the stable version v2.0.14, which correctly saves files to the same long paths.

Environment

• Operating System: Windows 11 Pro 24H2 (OS Build 26100.4351)
• Working Micro Version: v2.0.14 (Stable)
• Failing Micro Version: Nightly Build (e.g., 2025-07-01, 2025-6-30)
• System Configuration: Windows Long Path Support is enabled via the registry (LongPathsEnabled = 1).

Steps to Reproduce

1. On a Windows system with LongPathsEnabled set to 1 in the registry, install and run a recent nightly build of Micro.
2. Create a directory structure with a total path length exceeding 113 characters.
3. Open an existing file... Type some text to modify it and press Ctrl+S with Micro.

Expected Behavior

The file should save successfully without any errors, consistent with the behavior of the stable v2.0.14 release under the same conditions.

Example

The following two file paths demonstrate the issue. Both can be saved correctly by the stable v2.0.14 version.

• D:\Downloads\大大大大大大大大大大大大大大大大\大大大大大大\02_pytorch_claasificationGOOG.py

can save in the nightly build version,

but the

• D:\Downloads\大大大大大大大大大大大大大大大大\大大大大大大\02_pytorch_claasificationGOOOG.py

FAILS to save (The file fails to save. Micro displays an error message at the bottom).

Additional Context

This is a clear regression from the stable version. The issue is likely related to the build process of the nightly version for Windows, possibly concerning the application manifest that declares long path awareness.

Thank you for your work on this fantastic editor!

[dmaluka]

Looking at the 2nd screenshot, quite likely this is caused by #3273. @JoeKar

[JoeKar]

Damn, url.QueryEscape() converts such printable, but non-ASCII chars too...

But here we shouldn't forget, that the target file path still expands to:
backup_path = backup_dir + target_path
So in worst case the traditional ~256 characters are reduced by the backup directory path length.

Anyway url.QueryEscape() looks like a wrong decision for non-ASCII file names. 😓
So we need to find a better approach.

[JoeKar]

So we need to find a better approach.

A hash (e.g. SHA256) might be feasible, since we encode only and micro will represent the path which causes problems.

[dmaluka]

Nice idea. Or maybe MD5 (just because micro is already using it, for some other thing)?

[JoeKar]

We could use crypto/md5 here too, to lower additional dependencies.
I had doubts due to a slightly higher collision chance, but since none of them can prevent collision by 100% it most probably doesn't make a difference.

I will prepare a backward compatible fix for it.

[JoeKar]

To be considered as major and must-fix for milestone v2.0.15?
From my perspective: yes

[niten94]

This comment is irrelevant to the solution, but I was curious on why the backup path is invalid.

The nightly version of Micro converts the path below to a filename that is 255 bytes long:
D:\Downloads\大大大大大大大大大大大大大大大大\大大大大大大\02_pytorch_claasificationGOOG.py

Here, backup_path = backup_dir + converted_path exceeds 260 bytes which is the regular Win32 API path limit. However this succeeds (even without LongPathsEnabled=1 and manifest), because Go currently uses an undocumented method to enable long paths.

When one character is added, the backup filename exceeds the 255 character filename limit (not path). This causes the backup to fail, and can similarly be reproduced on Linux (!) which has a similar limit.