Opening/Set Location on a torrent with long paths (260+ characters) fails #12679

New issue

Closed

opened 2026-02-21 23:01:55 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-21 23:01:55 -05:00

Owner

Originally created by @Zerowalker on GitHub (Dec 22, 2021).

qBittorrent & operating system versions

qBittorrent: 4.3.9 x64
Operating system: Windows 10 Pro 21H1 x64 10.0.19043
Qt: 5.15.2
libtorrent-rasterbar: 1.2.14

What is the problem?

Opening a file that has too long of a path (260+ characters) doesn't seem to work, while opening it manually inside the folder does (assumes it depends if the application opening actually supports long paths though).
Using "set location" to move a torrent where the paths are too long will fail, saying permissions is denied.
But downloading the torrent and creating those long paths works just fine, so it seems that some parts in qbittorrent doesn't properly handle long paths?

Steps to reproduce

Download a torrent so that the files/folder it creates ends up with paths having over 260 characters.
Try opening the files (have just tried media files here with mpc hc), it should open mpc hc and say "file not found"
2.1 Try using "set location" to move the torrent anywhere besides it's original location and it will fail with "permission denied".

Additional context

I sadly don't have the logs where it failed left, but in my case i found a workaround to moving the torrent which i might as well write here.

Create a junction to the torrent folder so that the path ends up being less than 260 characters.
Example:
Original: D:....\foo\bar.......\MyTorrent
Junction: D:\MyTorrent

(Junction is like a symlink, it points to a specific folder like a shortcut, but it acts just like the original folder,
but the path will be altered, so it's a trick to shorten paths).
Alternatively you might be able to use 8.3 paths, though they are usually disabled i think, but one can manually generate them i believe, but i think this is a bit messier than the junction method.

Now in qBittorrent you use "set location" and tell it to change to "D:\MyTorrent", it will then recheck the data there first before attempting to move i think, cause after it rechecks and sees that it's 100% valid, it will just assume that it has been moved (even though it didn't move anything?).

The files/folders are now in a shorter paths and you can just use "set location" again to move it to wherever you want (except if the destination ends up with long path names i guess, haven't tested that yet).

Log(s) & preferences file(s)

No response

Originally created by @Zerowalker on GitHub (Dec 22, 2021). ### qBittorrent & operating system versions qBittorrent: 4.3.9 x64 Operating system: Windows 10 Pro 21H1 x64 10.0.19043 Qt: 5.15.2 libtorrent-rasterbar: 1.2.14 ### What is the problem? Opening a file that has too long of a path (260+ characters) doesn't seem to work, while opening it manually inside the folder does (assumes it depends if the application opening actually supports long paths though). Using "set location" to move a torrent where the paths are too long will fail, saying permissions is denied. But downloading the torrent and creating those long paths works just fine, so it seems that some parts in qbittorrent doesn't properly handle long paths? ### Steps to reproduce 1. Download a torrent so that the files/folder it creates ends up with paths having over 260 characters. 2. Try opening the files (have just tried media files here with mpc hc), it should open mpc hc and say "file not found" 2.1 Try using "set location" to move the torrent anywhere besides it's original location and it will fail with "permission denied". ### Additional context I sadly don't have the logs where it failed left, but in my case i found a workaround to moving the torrent which i might as well write here. Create a junction to the torrent folder so that the path ends up being less than 260 characters. Example: Original: D:\....\foo\bar\....\...\MyTorrent Junction: D:\MyTorrent (Junction is like a symlink, it points to a specific folder like a shortcut, but it acts just like the original folder, but the path will be altered, so it's a trick to shorten paths). Alternatively you might be able to use 8.3 paths, though they are usually disabled i think, but one can manually generate them i believe, but i think this is a bit messier than the junction method. Now in qBittorrent you use "set location" and tell it to change to "D:\MyTorrent", it will then recheck the data there first before attempting to move i think, cause after it rechecks and sees that it's 100% valid, it will just assume that it has been moved (even though it didn't move anything?). The files/folders are now in a shorter paths and you can just use "set location" again to move it to wherever you want (except if the destination ends up with long path names i guess, haven't tested that yet). ### Log(s) & preferences file(s) _No response_

deekerman

2026-02-21 23:01:55 -05:00

closed this issue
added the
OS: Windows
label

deekerman commented

2026-02-21 23:02:11 -05:00

Author

Owner

@Zerowalker commented on GitHub (Dec 22, 2021):

Oh right, if it matters i got "Enable Long Paths" enabled, but i am actually not sure what it even does,
as it clearly doesn't just solve it, cause Explorer itself can't handle long paths anyway.
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later

EDIT:

Though according to the documentation it looks like the basic WinAPI functions for handling files/folders won't have any restrictions if this is enabled, so i am quite interested how qBittorrent handles this as it seems it doesn't help.
I am guessing it either utilizes explorer (which doesn't support it?), or it has the limit hardcoded?

@Zerowalker commented on GitHub (Dec 22, 2021): Oh right, if it matters i got "Enable Long Paths" enabled, but i am actually not sure what it even does, as it clearly doesn't just solve it, cause Explorer itself can't handle long paths anyway. https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd#enable-long-paths-in-windows-10-version-1607-and-later EDIT: Though according to the documentation it looks like the basic WinAPI functions for handling files/folders won't have any restrictions if this is enabled, so i am quite interested how qBittorrent handles this as it seems it doesn't help. I am guessing it either utilizes explorer (which doesn't support it?), or it has the limit hardcoded?

deekerman commented

2026-02-21 23:02:11 -05:00

Author

Owner

@xavier2k6 commented on GitHub (Jul 23, 2025):

This ticket has been closed.

Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.

If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Thank you for your contribution(s).

NOTE: This ticket will be locked in ~30 Days to avoid any necroing.

@xavier2k6 commented on GitHub (Jul 23, 2025): ### This ticket has been closed. ____ **Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.** ____ * If you experience the reported problem or similar in the **latest** version, please open a new issue report with the requested information in the issue template. * Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar. * Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression. * A new issue report with relevant updated data gathered from the **latest** version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression. * Thank you for your contribution(s). ____ **NOTE: This ticket will be locked in ~30 Days to avoid any necroing.**