[PR #10787] Add limit on metadata pathlength (revised) #12611

New Issue

OVERLORD · 2026-02-07T06:58:49+03:00

OVERLORD commented

2026-02-07 06:58:49 +03:00

Original Pull Request: https://github.com/jellyfin/jellyfin/pull/10787

State: open
Merged: No

Changes
Modify BaseXmlSaver and BaseNfoSaver to prevent metadata directory of excessive length from being created. On Windows, extended-path notation ("\\?\") is used, and on Unix-like systems, the created directory is kept shorter than 255 characters (in-line with the most common Unix-like filesystem NAME_MAX value).

Notes
There are a couple of things to note about this changes:

This is a revision of #10784, which I decided to close after realizing that I had misunderstood the role of savers and created an ineffective solution.
This does not tailor a solution to individual filesystems, each of which usually have a different NAME_MAX. This is intentional, as every commonly-used filesystem has a NAME_MAX greater than or equal to 255, so keeping it at this value seems reasonable.
I did not implement a solution to capping the path at 4096 characters (again, the most common Unix-like filesystem PATH_MAX by far) since this seemed redundant when the issue at hand is that automatically-retrieved metadata can result in folders of length greater than NAME_MAX being created. It's unlikely that any metadata item would come anywhere near this value, and I think it makes more sense to leave this as an error to be handled due to the difficulty in working around it.

Issues
#10780

**Original Pull Request:** https://github.com/jellyfin/jellyfin/pull/10787 **State:** open **Merged:** No --- **Changes** Modify BaseXmlSaver and BaseNfoSaver to prevent metadata directory of excessive length from being created. On Windows, extended-path notation ("\\\\?\\") is used, and on Unix-like systems, the created directory is kept shorter than 255 characters (in-line with the most common Unix-like filesystem NAME_MAX value). **Notes** There are a couple of things to note about this changes: 1. This is a revision of #10784, which I decided to close after realizing that I had misunderstood the role of savers and created an ineffective solution. 2. This does not tailor a solution to individual filesystems, each of which usually have a different NAME_MAX. This is intentional, as every commonly-used filesystem has a NAME_MAX greater than or equal to 255, so keeping it at this value seems reasonable. 3. I did not implement a solution to capping the path at 4096 characters (again, the most common Unix-like filesystem PATH_MAX by far) since this seemed redundant when the issue at hand is that automatically-retrieved metadata can result in folders of length greater than NAME_MAX being created. It's unlikely that any metadata item would come anywhere near this value, and I think it makes more sense to leave this as an error to be handled due to the difficulty in working around it. **Issues** #10780

OVERLORD added the pull-request label 2026-02-07 06:58:49 +03:00

Sign in to join this conversation.

Branches Tags

master

renovate/major-skiasharp-monorepo

renovate/sharpcompress-0.x

renovate/svg.skia-5.x

renovate/ghcr.io-devcontainers-features-docker-in-docker-4.x

release-10.11.z

standards-fix

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#12611