Issue with very long file names #4

Author

Owner

@cdumez commented on GitHub (Aug 12, 2012):

Do you have such torrent you can share with me so that I can reproduce? (email: chris(at)qbittorrent(dot)org)

@cdumez commented on GitHub (Aug 12, 2012): Do you have such torrent you can share with me so that I can reproduce? (email: chris(at)qbittorrent(dot)org)

deekerman commented

Author

Owner

@cdumez commented on GitHub (Aug 12, 2012):

Basically, NTFS requires the file path to be 255 characters maximum. This includes the save path and the file name, e.g:
"C:\My very very very long path\Download\My Super Great Album with a very long name\01 - My Super Great Album with a very long name - My very very long song title.mp3" is 166 characters.

I have checked qBittorrent code and it appears I'm not doing anything to address this issue anymore (probably removed it a while back because it wasn't working properly). Of course, I could try to truncate the file names in the torrent to try to avoid reaching the FS limitation. However, this is not a perfect solution because if the save path length is already more than 255 characters, then there is nothing qBittorrent can do.

Are you saving to a very long save path or is it really the torrent file that has a huge file name?

@cdumez commented on GitHub (Aug 12, 2012): Basically, NTFS requires the file path to be 255 characters maximum. This includes the save path and the file name, e.g: "C:\My very very very long path\Download\My Super Great Album with a very long name\01 - My Super Great Album with a very long name - My very very long song title.mp3" is 166 characters. I have checked qBittorrent code and it appears I'm not doing anything to address this issue anymore (probably removed it a while back because it wasn't working properly). Of course, I could try to truncate the file names in the torrent to try to avoid reaching the FS limitation. However, this is not a perfect solution because if the save path length is already more than 255 characters, then there is nothing qBittorrent can do. Are you saving to a very long save path or is it really the torrent file that has a huge file name?

deekerman commented

Author

Owner

@drakkenson commented on GitHub (Aug 12, 2012):

There is one file with a very long filename, inside a folder with a very
long filename. The torrent filename itself is short.

On Sun, Aug 12, 2012 at 10:23 AM, Christophe Dumez <notifications@github.com

wrote:

Basically, NTFS requires the file path to be 255 characters maximum. This
includes the save path and the file name, e.g:
"C:\My very very very long path\Download\My Super Great Album with a very
long name\01 - My Super Great Album with a very long name - My very very
long song title.mp3" is 166 characters.

I have checked qBittorrent code and it appears I'm not doing anything to
address this issue anymore (probably removed it a while back because it
wasn't working properly). Of course, I could try to truncate the file names
in the torrent to try to avoid reaching the FS limitation. However, this is
not a perfect solution because if the save path length is already more than
255 characters, then there is nothing qBittorrent can do.

Are you saving to a very long save path or is it really the torrent file
that has a huge file name?

—
Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/18#issuecomment-7673471.

@drakkenson commented on GitHub (Aug 12, 2012): There is one file with a very long filename, inside a folder with a very long filename. The torrent filename itself is short. On Sun, Aug 12, 2012 at 10:23 AM, Christophe Dumez <notifications@github.com > wrote: > > Basically, NTFS requires the file path to be 255 characters maximum. This > includes the save path and the file name, e.g: > "C:\My very very very long path\Download\My Super Great Album with a very > long name\01 - My Super Great Album with a very long name - My very very > long song title.mp3" is 166 characters. > > I have checked qBittorrent code and it appears I'm not doing anything to > address this issue anymore (probably removed it a while back because it > wasn't working properly). Of course, I could try to truncate the file names > in the torrent to try to avoid reaching the FS limitation. However, this is > not a perfect solution because if the save path length is already more than > 255 characters, then there is nothing qBittorrent can do. > > Are you saving to a very long save path or is it really the torrent file > that has a huge file name? > > — > Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/18#issuecomment-7673471.

deekerman commented

Author

Owner

@drakkenson commented on GitHub (Aug 12, 2012):

About a solution, perhaps you could include an option to just not download
the problem file at all, if all else fails. I am not sure if this is
feasible, though...

On Sun, Aug 12, 2012 at 10:23 AM, Christophe Dumez <notifications@github.com

wrote:

Basically, NTFS requires the file path to be 255 characters maximum. This
includes the save path and the file name, e.g:
"C:\My very very very long path\Download\My Super Great Album with a very
long name\01 - My Super Great Album with a very long name - My very very
long song title.mp3" is 166 characters.

I have checked qBittorrent code and it appears I'm not doing anything to
address this issue anymore (probably removed it a while back because it
wasn't working properly). Of course, I could try to truncate the file names
in the torrent to try to avoid reaching the FS limitation. However, this is
not a perfect solution because if the save path length is already more than
255 characters, then there is nothing qBittorrent can do.

Are you saving to a very long save path or is it really the torrent file
that has a huge file name?

—
Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/18#issuecomment-7673471.

@drakkenson commented on GitHub (Aug 12, 2012): About a solution, perhaps you could include an option to just not download the problem file at all, if all else fails. I am not sure if this is feasible, though... On Sun, Aug 12, 2012 at 10:23 AM, Christophe Dumez <notifications@github.com > wrote: > > Basically, NTFS requires the file path to be 255 characters maximum. This > includes the save path and the file name, e.g: > "C:\My very very very long path\Download\My Super Great Album with a very > long name\01 - My Super Great Album with a very long name - My very very > long song title.mp3" is 166 characters. > > I have checked qBittorrent code and it appears I'm not doing anything to > address this issue anymore (probably removed it a while back because it > wasn't working properly). Of course, I could try to truncate the file names > in the torrent to try to avoid reaching the FS limitation. However, this is > not a perfect solution because if the save path length is already more than > 255 characters, then there is nothing qBittorrent can do. > > Are you saving to a very long save path or is it really the torrent file > that has a huge file name? > > — > Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/18#issuecomment-7673471.

deekerman commented

Author

Owner

@vinit-agr commented on GitHub (Aug 16, 2012):

As drakkenson said , i think in these cases such files should be either prioritized lowest or just need to be saved to some other location with some other file name, and later when a user selects the torrent their should be a popup or a message to change the file location and/or name to fit in the file system limits. that way the download process can continue and all is left is to rename or relocate it.

@vinit-agr commented on GitHub (Aug 16, 2012): As drakkenson said , i think in these cases such files should be either prioritized lowest or just need to be saved to some other location with some other file name, and later when a user selects the torrent their should be a popup or a message to change the file location and/or name to fit in the file system limits. that way the download process can continue and all is left is to rename or relocate it.

deekerman commented

Author

Owner

@sbibayoff commented on GitHub (Sep 20, 2012):

I am having this problem also.

System: Ubuntu 12.04 LTS
qBittorrent v2.9.7
Qt: 4.8.0
libtorrent:0.15.10.0
Boost 1.46.1

Tried to disabling downloading offending file and chancing priority.
Keep getting:
20/09/2012 01:56:46 - An I/O error occured, 'torrent' paused.
(torrent name changed to "torrent")

Anything else needed?

@sbibayoff commented on GitHub (Sep 20, 2012): I am having this problem also. System: Ubuntu 12.04 LTS qBittorrent v2.9.7 Qt: 4.8.0 libtorrent:0.15.10.0 Boost 1.46.1 Tried to disabling downloading offending file and chancing priority. Keep getting: 20/09/2012 01:56:46 - An I/O error occured, 'torrent' paused. (torrent name changed to "torrent") Anything else needed?

deekerman commented

Author

Owner

@452 commented on GitHub (Sep 20, 2012):

maybe need qBittorent check filename length and also path length if so long check .torrent isCanBeRenamedToTempFileName like "a.avi" or if it's not give any good result then try create downloaded files in temp folders then move or copy to destination or and try rename to normal file name.
I try to learn English =)

@452 commented on GitHub (Sep 20, 2012): maybe need qBittorent check filename length and also path length if so long check .torrent isCanBeRenamedToTempFileName like "a.avi" or if it's not give any good result then try create downloaded files in temp folders then move or copy to destination or and try rename to normal file name. I try to learn English =)

deekerman commented

Author

Owner

@darkstar commented on GitHub (Sep 24, 2012):

The fact that NTFS supports only 255 characters (actually 260, or MAX_PATH) in a path is wrong. It's the WIN32 API that enforces that limitation. You can prefix the paths with ?\ to increase the limit to 32k.

See for example here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

@darkstar commented on GitHub (Sep 24, 2012): The fact that NTFS supports only 255 characters (actually 260, or MAX_PATH) in a path is wrong. It's the WIN32 API that enforces that limitation. You can prefix the paths with \?\ to increase the limit to 32k. See for example here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

deekerman commented

Author

Owner

@deucalion commented on GitHub (Nov 20, 2012):

The first limit imposed by most OS's is the filename (and not the pathname) limit, which is usually 255 characters. Linux has a shorter leash on users than NTFS/Windows... Linux limits paths to 4096 characters (cf: http://serverfault.com/a/306726/116393 ) whereas (as previously mentioned) NT allows 32k long paths.

Does this issue still occur?

@deucalion commented on GitHub (Nov 20, 2012): The first limit imposed by most OS's is the filename (and not the pathname) limit, which is usually 255 characters. Linux has a shorter leash on users than NTFS/Windows... Linux limits paths to 4096 characters (cf: http://serverfault.com/a/306726/116393 ) whereas (as previously mentioned) NT allows 32k long paths. Does this issue still occur?

deekerman commented

Author

Owner

@Alexei95 commented on GitHub (Nov 20, 2012):

It depends only on the filesystem you use.
ext2, ext3, ext4, zfs and (maybe?) also btrfs have no limits for pathname length but a 255-character limit for filename length. Consider that it's very difficult to reach 255 characters for only the filename (if you see above, cdumez makes an example of a pathname with 166 characters) unless you write a complete period in the filename. In that case you could have problems. :)

@Alexei95 commented on GitHub (Nov 20, 2012): It depends only on the filesystem you use. ext2, ext3, ext4, zfs and (maybe?) also btrfs have no limits for pathname length but a 255-character limit for filename length. Consider that it's very difficult to reach 255 characters for only the filename (if you see above, cdumez makes an example of a pathname with 166 characters) unless you write a complete period in the filename. In that case you could have problems. :)

deekerman commented

https://code.google.com/p/libtorrent/issues/detail?id=423

Author

Owner

@Gelmir commented on GitHub (Feb 26, 2013):

Bump.

In short: truncation of multibyte-encoded filenames is broken, because the string is treated as signle-byte in libtorrent.

@Gelmir commented on GitHub (Feb 26, 2013): **Bump.** https://code.google.com/p/libtorrent/issues/detail?id=423 In short: truncation of multibyte-encoded filenames is broken, because the string is treated as signle-byte in libtorrent.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Mar 9, 2013):

Fixed upstream. Closing. New version of qbt will be compiled with the fix included.

@sledgehammer999 commented on GitHub (Mar 9, 2013): Fixed upstream. Closing. New version of qbt will be compiled with the fix included.

deekerman commented

Author

Owner

@ghost commented on GitHub (Jul 2, 2013):

This is not fixed in v3.0.9. Am getting filename too long error on Ext4.

@ghost commented on GitHub (Jul 2, 2013): This is not fixed in v3.0.9. Am getting filename too long error on Ext4.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jul 2, 2013):

@moorej What is your OS? What libtorrent version are you using(help->about->libraries). Can you post a link to the torrent file?

The fix was released with 0.16.9 but I think it was Windows specific.

@sledgehammer999 commented on GitHub (Jul 2, 2013): @moorej What is your OS? What libtorrent version are you using(help->about->libraries). Can you post a link to the torrent file? The fix was released with 0.16.9 but I think it was Windows specific.

deekerman commented

Author

Owner

@ghost commented on GitHub (Jul 5, 2013):

@sledgehammer999
Qt: 4.8.4
Libtorrent: 0.16.7.0
Boost: 1.49.0
Linux xxxx 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

@ghost commented on GitHub (Jul 5, 2013): @sledgehammer999 Qt: 4.8.4 Libtorrent: 0.16.7.0 Boost: 1.49.0 Linux xxxx 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

deekerman commented

2026-02-21 14:48:33 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 5, 2013):

Which version of Ubuntu(although not really important)?
We need a torrent file to test. Do you have one that exhibits the bug?

@sledgehammer999 commented on GitHub (Jul 5, 2013): Which version of Ubuntu(although not really important)? We need a torrent file to test. Do you have one that exhibits the bug?

deekerman commented

Author

Owner

@ghost commented on GitHub (Jul 5, 2013):

Xubuntu 13.04.
Yes I can email it. Have an email?

@ghost commented on GitHub (Jul 5, 2013): Xubuntu 13.04. Yes I can email it. Have an email?

deekerman commented

2026-02-21 14:48:33 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 6, 2013):

Send it to sledgehammer999 at qbittorrent.org

@sledgehammer999 commented on GitHub (Jul 6, 2013): Send it to sledgehammer999 at qbittorrent.org

deekerman commented

2026-02-21 14:48:33 -05:00

Author

Owner

@ghost commented on GitHub (Jul 9, 2013):

I've been having this problem as well, and to solve it I formatted a 32GiB flash drive to FAT32, and changed the download directory to the flash drive, which worked, but oddly enough it also worked when I changed the download directory to my 1 terabyte portable drive, which has a HPFS/NTFS partition, normally I'd say its due to it being a different format, but both my boot drive and my portable one are both Ext4, due to this I'm thinking it might be something with either the local drive(which my OS, Ubuntu 13.04 32 bit, boots from) or something to do with locally mounted drives(which would be a bit more difficult to test, haven't had the opportunity to pick up an extra hard drive) so I give the bootable drives a test and post the results, anyone want to test my idea on the locally mounted drive? Or it might just be the fact that I'm downloading torrents to an external source(might work also on a formatted SD card for all I know) either way this is at least a bit of an ad hoc fix.

@ghost commented on GitHub (Jul 9, 2013): I've been having this problem as well, and to solve it I formatted a 32GiB flash drive to FAT32, and changed the download directory to the flash drive, which worked, but oddly enough it also worked when I changed the download directory to my 1 terabyte portable drive, which has a HPFS/NTFS partition, normally I'd say its due to it being a different format, but both my boot drive and my portable one are both Ext4, due to this I'm thinking it might be something with either the local drive(which my OS, Ubuntu 13.04 32 bit, boots from) or something to do with locally mounted drives(which would be a bit more difficult to test, haven't had the opportunity to pick up an extra hard drive) so I give the bootable drives a test and post the results, anyone want to test my idea on the locally mounted drive? Or it might just be the fact that I'm downloading torrents to an external source(might work also on a formatted SD card for all I know) either way this is at least a bit of an ad hoc fix.

deekerman commented

Author

Owner

@Damienbarifon commented on GitHub (Nov 4, 2015):

Try to long path tool. It is very helpful.

@Damienbarifon commented on GitHub (Nov 4, 2015): Try to long path tool. It is very helpful.

deekerman commented

Author

Owner

@marcpoch commented on GitHub (Apr 14, 2016):

I confirm this bug persists on ext4 FS.
You can skip the error saving the downloaded content into a FAT32 partition.

@marcpoch commented on GitHub (Apr 14, 2016): I confirm this bug persists on ext4 FS. You can skip the error saving the downloaded content into a FAT32 partition.

deekerman commented

Author

Owner

@pinnerup commented on GitHub (Nov 9, 2016):

I also have this (or a very similar) issue running 3.3.6-1build1 on the most recent version of Ubuntu (Yakkety Yak, Ubuntu 16.10).

@pinnerup commented on GitHub (Nov 9, 2016): I also have this (or a very similar) issue running 3.3.6-1build1 on the most recent version of Ubuntu (Yakkety Yak, Ubuntu 16.10).

deekerman commented