Export to Markdown truncates notebook/folder names to 50 characters

Joplin Desktop
Version: 1.67.1 (user setup)
Commit: da15b6fd3ef856477bf6f4fb29ba1b7af717770d
Windows 11

When I File > Export using either of the Markdown formats, my notebook names are truncated to 50 characters generating the folder name.

Is this by design? If so, why?

See below for the reasoning given:

This is working as expected since we have to limit the number of characters in the file path. We have tried many different limits and 50 is a good compromise.

and: joplin/packages/lib/path-utils.ts at 0cec4753d8afaa5673eba526c121d8b1e1062a5d · laurent22/joplin · GitHub

// Although Windows supports paths up to 255 characters, but that includes the filename and its
// parent directory path. Also there's generally no good reason for dir or file names
// to be so long, so keep it at 50, which should prevent various errors.

1 Like

Thank you, @Daeraxa. I was just looking at the source code.

While I understand the reasoning, I don't agree with it because

  1. It imposes a limit on the platform instead of checking the platform's limits
  2. It doesn't solve the root problem; path limit errors will still occur
  3. It silently modifies the user's data

I've read the several forum arguments about export fidelity, and I understand this is a hard problem when supporting multiple platforms, no "note" standard, etc.

Path length limit
I agree there's a path limit per platform. But the Windows MAX_PATH limit of 255 isn't generally valid anymore. 32,767 characters is the norm. Maximum Path Length Limitation - Win32 apps | Microsoft Docs

I know it's more work than using a hard 50 character limit, but wouldn't there be value in checking the running platform's capabilities? Check the installed platform's path limit and only truncate if exceeding that limit. The InteropService_Exporter_Md.ts makeDirPath method could perform this check, or move the functionality to path-utils.ts.

Silent modification
JEX is Joplin's high-fidelity export/import format. Understood. The point I'm making here isn't fidelity, but user-friendliness. If an export is going to change user data, which the 50 character limit does, then the user should be informed according to the Principle of Least Surprise.

I may write this up as a formal feature request (or work on a pull request, which is what I should do, right?). Basically, the app should keep track of when paths are truncated during export and provide a report of those changes.

Potential Bug
When I perform a Markdown export of my Joplin notebooks, I can't delete the resulting folder using File Explorer. I must use the Command shell and run rmdir [dir] /s /q. While this is arguably an OS issue, it's still being caused by the Joplin truncation. Only the truncated folders have a problem. Note: I think this may be due to Joplin not trimming the folder name, resulting in trailing spaces.

Typescript/Javascript limitation?
Are we coming up against a limitation in using Node/Typescript/Javascript to interact with the operating system? Maybe, although I see several Win32 packages in NPM. But I'd have to dig deeper and prototype to be sure.

Wrap Up
I hope this discussion helps provide a user's point of view on problems with truncating folder/file names on export, as well as respecting the development challenge in improving those exports. A report of truncated paths would go a long way toward an improved user experience.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.