starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-07-16 05:43:54 +03:00
Code Issues 822 Packages Projects Releases 17 Wiki Activity

[PR #5775] [CLOSED] Work around symbolic link issue on Linux #10654

New Issue
Closed
opened 2026-02-07 06:24:20 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-07 06:24:20 +03:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/5775
Author: @Orochimarufan
Created: 4/11/2021
Status: ❌ Closed

Base: master ← Head: unixfile

📝 Commits (1)

  • f782dc3 Add UnixPhysicalFileResultExecutor

📊 Changes

3 files changed (+136 additions, -0 deletions)

View changed files

📝 Jellyfin.Server/Jellyfin.Server.csproj (+5 -0)
➕ Jellyfin.Server/Middleware/UnixPhysicalFileResultExecutor.cs (+122 -0)
📝 Jellyfin.Server/Startup.cs (+9 -0)

📄 Description

In 10.7.x the direct file streams were switched to PhysicalFileResult. This has introduced a regression because System.IO.FileInfo (and by extension PhysicalFileResultExecutor) don't handle symbolic links correctly.
More specifically, System.IO.FileInfo will report the symlink size instead of the target size. This means PhysicalFileResultExecutor will only ever try to send a few bytes of a symlinked file.
The fix for the upstream issue has been moved back to .NET 6 so it would be nice to work around the regression in the mean time.

This is a working replacement for PhysicalFileResultExecutor based on Mono.Posix which has proper handling of symbolic links. However, it does introduce an additional dependency. It has been tested on amd64 and aarch64 Linux. I'd expect it to work just as well on macOS, provided the platform check is extended, but I have no means of verifying this claim.

An analogous solution might also be viable on Windows, but I don't know enough about Win32 to take a shot at it.
Alternatively, it may be possible to achieve a similar effect using the open-seek-tell workaround.

Note that this is my first time working with ASP.NET, so I'd welcome suggestions.

Changes
Add custom ResultExecutor for PhysicalFileResult based on Mono.Posix

Issues
Fixes #5521 on Linux

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/5775 **Author:** [@Orochimarufan](https://github.com/Orochimarufan) **Created:** 4/11/2021 **Status:** ❌ Closed **Base:** `master` ← **Head:** `unixfile` --- ### 📝 Commits (1) - [`f782dc3`](https://github.com/jellyfin/jellyfin/commit/f782dc3e812fbb6c210bafb82ad3ffdbf41ddbdb) Add UnixPhysicalFileResultExecutor ### 📊 Changes **3 files changed** (+136 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `Jellyfin.Server/Jellyfin.Server.csproj` (+5 -0) ➕ `Jellyfin.Server/Middleware/UnixPhysicalFileResultExecutor.cs` (+122 -0) 📝 `Jellyfin.Server/Startup.cs` (+9 -0) </details> ### 📄 Description In 10.7.x the direct file streams were switched to PhysicalFileResult. This has introduced a regression because System.IO.FileInfo (and by extension PhysicalFileResultExecutor) don't handle symbolic links correctly. More specifically, System.IO.FileInfo will report the symlink size instead of the target size. This means PhysicalFileResultExecutor will only ever try to send a few bytes of a symlinked file. The fix for the upstream issue has been moved back to .NET 6 so it would be nice to work around the regression in the mean time. This is a working replacement for PhysicalFileResultExecutor based on Mono.Posix which has proper handling of symbolic links. However, it does introduce an additional dependency. It has been tested on amd64 and aarch64 Linux. I'd expect it to work just as well on macOS, provided the platform check is extended, but I have no means of verifying this claim. An analogous solution might also be viable on Windows, but I don't know enough about Win32 to take a shot at it. Alternatively, it may be possible to achieve a similar effect using the open-seek-tell workaround. Note that this is my first time working with ASP.NET, so I'd welcome suggestions. **Changes** Add custom ResultExecutor for PhysicalFileResult based on Mono.Posix **Issues** Fixes #5521 on Linux --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
OVERLORD added the pull-request label 2026-02-07 06:24:20 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#10654
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?