starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Client allows user to make folders with illegal folder names #15488

New issue

Open

opened 2026-02-22 02:10:55 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-22 02:10:55 -05:00

Owner

Originally created by @SparkySparkinson on GitHub (Feb 12, 2024).

qBittorrent & operating system versions

qBittorrent: 4.6.3 x64
Operating System: Windows 10 Pro 22H2 (19045.3930) x64 (10.0.19045)
< I am not sure what else to put here so ask and I'll give more info >

What is the problem?

Client allows user to create folders with illegal names (names containing trailing/leading whitespaces), causing issues with indexing and later access of the files

Steps to reproduce

Open .torrent file
Set download dir to anything with trailing whitespace. E.g. "F:\foo \boo"
Assuming a "F:\foo\coo" already exists, both definitions of foo coexist and the new directory may or may not be accessible.
Deleting both instances of foo leads to error "Could not find this item" on the "F:\foo " folder.
User will have to go into powershell to manually remove the problematic foo.

Additional context

Log(s) & preferences file(s)

No response

Originally created by @SparkySparkinson on GitHub (Feb 12, 2024). ### qBittorrent & operating system versions qBittorrent: 4.6.3 x64 Operating System: Windows 10 Pro 22H2 (19045.3930) x64 (10.0.19045) < I am not sure what else to put here so ask and I'll give more info > ### What is the problem? Client allows user to create folders with illegal names (names containing trailing/leading whitespaces), causing issues with indexing and later access of the files ### Steps to reproduce 1. Open .torrent file 2. Set download dir to anything with trailing whitespace. E.g. "F:\foo \boo" 3. Assuming a "F:\foo\coo" already exists, both definitions of foo coexist and the new directory may or may not be accessible. 4. Deleting both instances of foo leads to error "Could not find this item" on the "F:\foo " folder. 5. User will have to go into powershell to manually remove the problematic foo. ### Additional context ![image](https://github.com/qbittorrent/qBittorrent/assets/143802560/f857e5fd-9920-498c-9649-54954d5ce1bb) ![image](https://github.com/qbittorrent/qBittorrent/assets/143802560/49e52fc9-4014-49ba-9777-d28268e4bdbc) ### Log(s) & preferences file(s) _No response_

deekerman added the

OS: Windows

Duplicate

labels

2026-02-22 02:10:55 -05:00

deekerman commented

2026-02-22 02:11:00 -05:00

Author

Owner

@glassez commented on GitHub (Feb 12, 2024):

OS won't allow you to create folder with illegal name. The above names are legal, although poorly supported by some software (especially GUI software like Windows Explorer).

@glassez commented on GitHub (Feb 12, 2024): OS won't allow you to create folder with illegal name. The above names are legal, although poorly supported by some software (especially GUI software like Windows Explorer).

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Feb 12, 2024):

@glasses, I would argue that we should follow https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

@HanabishiRecca commented on GitHub (Feb 12, 2024): @glasses, I would argue that we should follow https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions > Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@SparkySparkinson commented on GitHub (Feb 12, 2024):

@glassez I understand that most GUIs don't support it but I do feel that it is something that is worth implementing. Sure, the Client may be able to do things that the user is unable to, but this leads to unwanted situations that causes problem for the user if they are not aware of it. In my case, boo was inaccessible no matter what I tried, and only coo appeared if I clicked on both instances of foo. I also perused around to find out if anyone else has the same issue, and I noticed this discussion on the mega github (https://github.com/meganz/MEGAsync/issues/706) where the web client allowed a name without warning the user that its not compatible with whatever system they are using it for. I believe that adding a simple workaround would improve usability of the client since me, as a CS student who is usually careful, made this mistake and had to dig around for a fix. The average user won't be able to do this.

@HanabishiRecca mentions a really good point, we should follow the naming convention of the most restrictive OS supported, or at the very least implement some safeguards that would prevent the user from doing dumb shit (intentionally or not). I would hazard a guess that if you accidentally used a reserved operator or reserved name, it would result in the same issue. I did not try this myself as I don't have the time to troubleshoot it should anything go wrong.

TLDR: OS won't allow you to create, but if the client creates it, there would be a problem. While it may be "legal" in some context, I consider anything in the grey area "illegal" because undefined behaviour is much worse than defined failures.

@SparkySparkinson commented on GitHub (Feb 12, 2024): @glassez I understand that most GUIs don't support it but I do feel that it is something that is worth implementing. Sure, the Client may be able to do things that the user is unable to, but this leads to unwanted situations that causes problem for the user if they are not aware of it. In my case, boo was inaccessible no matter what I tried, and only coo appeared if I clicked on both instances of foo. I also perused around to find out if anyone else has the same issue, and I noticed this discussion on the mega github (https://github.com/meganz/MEGAsync/issues/706) where the web client allowed a name without warning the user that its not compatible with whatever system they are using it for. I believe that adding a simple workaround would improve usability of the client since me, as a CS student who is usually careful, made this mistake and had to dig around for a fix. The average user won't be able to do this. @HanabishiRecca mentions a really good point, we should follow the naming convention of the most restrictive OS supported, or at the very least implement some safeguards that would prevent the user from doing dumb shit (intentionally or not). I would hazard a guess that if you accidentally used a reserved operator or reserved name, it would result in the same issue. I did not try this myself as I don't have the time to troubleshoot it should anything go wrong. TLDR: OS won't allow you to create, but if the client creates it, there would be a problem. While it may be "legal" in some context, I consider anything in the grey area "illegal" because undefined behaviour is much worse than defined failures.

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@glassez commented on GitHub (Feb 12, 2024):

OS won't allow you to create, but if the client creates it, there would be a problem.

This is nonsense. If the OS does not allow you to do something, then you will not be able to do it in any way. Try to create a file with a really invalid name - no client will be able to do this.

@glasses, I would argue that we should follow https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

I don't mind if someone contribute into it. But you should be very careful to implement this consistently. It doesn't look too difficult to prevent the user from creating such "unwanted" file/folder names through the qBittorrent interface. But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk.

@glassez commented on GitHub (Feb 12, 2024): > OS won't allow you to create, but if the client creates it, there would be a problem. This is nonsense. If the OS does not allow you to do something, then you will not be able to do it in any way. Try to create a file with a really invalid name - no client will be able to do this. > @glasses, I would argue that we should follow https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions > > > Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. I don't mind if someone contribute into it. But you should be very careful to implement this consistently. It doesn't look too difficult to prevent the user from creating such "unwanted" file/folder names through the qBittorrent interface. But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk.

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@SparkySparkinson commented on GitHub (Feb 12, 2024):

@glassez Ok maybe my terminology is wrong but the concept is still there. The user can't make a file named "foo " because whatever he interacts with won't let him. qbittorrent allows user to create "foo " which causes problems.

"But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk."

Maybe, but that's on the onus of the person who uploads the torrent for it to be accessible. If he creates a file/folder name that won't be able to be opened by a regular person downloading it, what is the point of even sharing the file/folder in the first place? Just because it exists doesn't mean it should be tolerated, especially if it can and will cause issues for the end user.

Anyways, that's not even the scope of this post, I'm just highlighting that a simple mistype (like I did the other day) can cause pain for people who aren't used to it

@SparkySparkinson commented on GitHub (Feb 12, 2024): @glassez Ok maybe my terminology is wrong but the concept is still there. The user can't make a file named "foo " because whatever he interacts with won't let him. qbittorrent allows user to create "foo " which causes problems. > "But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk." Maybe, but that's on the onus of the person who uploads the torrent for it to be accessible. If he creates a file/folder name that won't be able to be opened by a regular person downloading it, what is the point of even sharing the file/folder in the first place? Just because it exists doesn't mean it should be tolerated, especially if it can and will cause issues for the end user. Anyways, that's not even the scope of this post, I'm just highlighting that a simple mistype (like I did the other day) can cause pain for people who aren't used to it

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Feb 13, 2024):

If the OS does not allow you to do something, then you will not be able to do it in any way.

Well, an unfortunate truth is that you can. Especially with UNC paths, it is totally possible to create files with the reserved names. Windows at its finest.

But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk.

Btw, libtorrent does try to sanitize some names in non-UNC mode.

github.com/arvidn/libtorrent@3770d170c1/src/torrent_info.cpp (L181-L210)

But this is not the default. I belive it is currently totally possible to have a torrent with unaccessible content in Windows Exporer (and most other apps), despite the client working fine with it via UNC.

I.e. same situation as with this issue.

@HanabishiRecca commented on GitHub (Feb 13, 2024): > If the OS does not allow you to do something, then you will not be able to do it in any way. Well, an unfortunate truth is that you can. Especially with UNC paths, it is totally possible to create files with the reserved names. Windows at its finest. > But it should also be borne in mind that such names may already exist in the metadata of torrents and even in files/folders on the disk. Btw, libtorrent does try to sanitize some names in non-UNC mode. https://github.com/arvidn/libtorrent/blob/3770d170c1bb28951a727d151d67579c229a3dd6/src/torrent_info.cpp#L181-L210 But this is not the default. I belive it is currently totally possible to have a torrent with unaccessible content in Windows Exporer (and most other apps), despite the client working fine with it via UNC. I.e. same situation as with this issue.

deekerman commented

2026-02-22 02:11:05 -05:00

Author

Owner

@cocopaw commented on GitHub (Aug 22, 2025):

The Windows filesystem (NTFS) and its write APIs do allow certain "reserved" characters or patterns—like leading/trailing spaces, periods (.), double periods (..), backslashes (), forward slashes (/), and others—to be used in filenames and paths under specific programmatic circumstances. This is intentional because these elements are essential for low-level system operations and programmatic access:

. and .. are required for directory navigation (e.g., current and parent directories).
Spaces (including leading/trailing) are needed for compatibility with various path parsing and legacy applications.
\ and / serve as path separators in different contexts (e.g., Windows uses \ natively, but APIs often accept / for POSIX compatibility).

These are not outright forbidden by the kernel or filesystem; instead, the APIs expose them to enable advanced scripting, automation, or system tools (e.g., via PowerShell, as you mentioned for cleanup).

However, this flexibility doesn't mean applications like qBittorrent should expose these options directly to end-users. Microsoft's guidelines (e.g., in their documentation on file naming conventions) strongly recommend that user-facing applications validate and restrict these patterns to prevent exactly the kinds of issues you're describing: indexing problems, accessibility glitches, and errors like "Could not find this item." The rationale is to maintain a consistent, safe user experience—Explorer itself blocks leading/trailing spaces for this reason—while reserving the full API capabilities for developers or scripts that need them.

To address this, I have created a pull request (PR #23060) to add validation in qBittorrent that respects Windows reserved characters and blocks invalid folder names (e.g., ".", "..", control characters, names longer than 255 characters, and other reserved characters like <, >, :, ", /, , |, ?, *). This PR enhances stability by preventing these edge cases and aligns with Microsoft's best practices.

@cocopaw commented on GitHub (Aug 22, 2025): The Windows filesystem (NTFS) and its write APIs do allow certain "reserved" characters or patterns—like leading/trailing spaces, periods (.), double periods (..), backslashes (), forward slashes (/), and others—to be used in filenames and paths under specific programmatic circumstances. This is intentional because these elements are essential for low-level system operations and programmatic access: . and .. are required for directory navigation (e.g., current and parent directories). Spaces (including leading/trailing) are needed for compatibility with various path parsing and legacy applications. \ and / serve as path separators in different contexts (e.g., Windows uses \ natively, but APIs often accept / for POSIX compatibility). These are not outright forbidden by the kernel or filesystem; instead, the APIs expose them to enable advanced scripting, automation, or system tools (e.g., via PowerShell, as you mentioned for cleanup). However, this flexibility doesn't mean applications like qBittorrent should expose these options directly to end-users. Microsoft's guidelines (e.g., in their documentation on file naming conventions) strongly recommend that user-facing applications validate and restrict these patterns to prevent exactly the kinds of issues you're describing: indexing problems, accessibility glitches, and errors like "Could not find this item." The rationale is to maintain a consistent, safe user experience—Explorer itself blocks leading/trailing spaces for this reason—while reserving the full API capabilities for developers or scripts that need them. To address this, I have created a pull request ([PR #23060](https://github.com/qbittorrent/qBittorrent/pull/23060)) to add validation in qBittorrent that respects Windows reserved characters and blocks invalid folder names (e.g., ".", "..", control characters, names longer than 255 characters, and other reserved characters like <, >, :, ", /, , |, ?, *). This PR enhances stability by preventing these edge cases and aligns with Microsoft's best practices.