Sally 1.0.27: the Unicode and long-path milestone (experimental)

[0xeb]

Important

Sally 1.0.27 is now available for x64, x86, and Windows on ARM:
https://github.com/0xeb/sally/releases/tag/v1.0.27

Hi everyone,

Sally 1.0.27 is the largest internal update Sally has received so far.

This release completes a major migration of Sally’s core and bundled plugins to native Unicode text and dynamically owned long paths. The goal is simple: Sally should work with the real file name you selected, regardless of the Windows system locale or active code page.

Warning

Sally 1.0.27 should be considered experimental.

This change touches file operations, panels, dialogs, search, viewers, editors, archives, plugins, configuration, shell integration, and many other internal boundaries. It has received extensive automated and manual testing, but regressions and unexpected compatibility problems are still possible.

Please keep Sally 1.0.26 available until you have tested your normal workflows. If Sally is critical to your work, do not immediately replace your only trusted installation.

What has changed

• Native Unicode file names and paths throughout Sally’s core UI and file operations.
• Long-path-safe ownership without the old MAX_PATH-style internal limits.
• Better support for names containing CJK characters, Cyrillic, Greek, Arabic, Hebrew, emoji, and other text outside the active Windows code page.
• Unicode-aware Find, search, regular expressions, histories, configuration, diagnostics, clipboard, drag-and-drop, and shell integration.
• Bundled plugins migrated to wide/native paths, with explicit encoding only where a protocol or file format actually requires bytes.
• Ten translated language packs rebuilt for 1.0.27.
• The Editors and Viewers priority-list arrows now work correctly, addressing #108.

Behavior that may look different

Sorting now compares actual Unicode names instead of damaged code-page projections. This means files with non-ASCII names may appear in a different order than in older versions. That is intentional, although further sorting feedback is welcome.

Some very old third-party programs or external tools that only accept ANSI paths may reject names they cannot represent. Sally should now report that failure instead of silently changing the path and potentially targeting a different file.

Older third-party Sally plugins remain supported through an isolated compatibility layer, but plugin-specific regressions are possible after a migration this large.

I need your help testing it

Please test the workflows that matter to you, especially:

• Copy, move, delete, rename, and directory creation.
• Local, network, UNC, and long paths.
• ZIP, RAR, TAR, 7-Zip, and other archive operations.
• Find, viewers, editors, histories, and saved configuration.
• Clipboard, drag-and-drop, shell menus, and file associations.
• Third-party plugins.
• File and directory names containing non-ASCII text or emoji.

If something worked in 1.0.26 and fails in 1.0.27, please open an issue and include:

• Your Sally version and architecture.
• Your Windows version and system locale.
• Whether the problem also occurs in 1.0.26.
• Exact reproduction steps and the expected/actual result.
• Whether the affected path is local, network, inside an archive, longer than 260 characters, or contains non-ASCII characters.
• Screenshots and Help > Report a Bug output when available.

This migration has already uncovered and fixed many old assumptions that only appeared outside English/Western file names. Real-world reports are the best way to find the remaining ones.

Thank you to everyone who has tested Sally, reported issues, and helped make this milestone possible. The experimental 1.0.27 release is available for x64, x86, and Windows on ARM from the release page linked above.