Opened 5 years ago

Last modified 11 months ago

#4189 reopened Bug

Better handling of long torrent names

Reported by: kovalev Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 2.22
Severity: Minor Keywords:
Cc: stuart.bishop@…, nikoli@…


While running a torrent with very long name Transmission stops it periodically giving an error message: "Unable to save resume file: File name too long". The torrent however still can be restarted (until the next save of .resume file) and thus brought to completion.

The major cause of the issue seems is not in the Transmission code per se. However, since Transmission user is unable to modify any of the content of torrent created by the third party (including torrent name), it might be worth it to handle such situation more gracefully.

Observed in Transmission GTK 2.22+ (12305) build on Ubuntu 10.10 amd64, though other instances of the client might also be affected.

Change History (13)

comment:1 Changed 5 years ago by kovalev

  • Summary changed from Better handling of long filenames to Better handling of long torrent names

comment:2 Changed 5 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

It's a fair point. Thanks for reporting this.

However, I'm not really sure what Transmission should do in a case like this. Transmission inentionally keeps the original .torrent's filenames for its internal .torrent and .resume files, so that they'll be human-readable. Munging the names would lose that advantage, so we could be trading one problem for another.

We could try shortening the filenames until the "filename too long" error goes away, but really I think that's overengineering the problem. It's probably better to just punt the issue to the user with the "filename too long" problem.

comment:3 Changed 5 years ago by kovalev

  • Resolution invalid deleted
  • Status changed from closed to reopened

I totally agree with the point that it is up to users to keep their filenames in compliance with the system rules. Thus, there is absolutely no point in incorporating yet another piece of code to take additional care of the name of torrent file - it would be simply a bloat.

However, there is a difference between the "name of torrent file" and the "name of torrent". The latter one is stored (supposedly) among all other data inside a torrent file itself as a string, and users can only see it upon adding a torrent to the client. Once using a torrent file created by the third party, Transmission users cannot (and apparently should not) modify this value - unlike the name of the torrent file itself which can be altered by means of the OS to comply with it's rules.

Currently Transmission uses not the "name of torrent file" but the "name of torrent" to craft temporary file's names presumably assuming both are the same. Unfortunately it is not true in many instances. By the way, it results in yet another (and much more common) readability issue - temporary filenames often simply do not match the names of their parent torrent files... And it is precisely where is the issue: users are unable to resolve "filename too long" situation simply by renaming a torrent file...

Thus, I would still consider the issue as being worth it a fix - for instance, by simply using a "name of torrent file" instead of "name of torrent" for temporary files.

comment:4 Changed 5 years ago by jordan

  • Resolution set to wontfix
  • Status changed from reopened to closed metadata passed in the most common mechanism, from a web browser via a temporary file, would still be affected by the issue.

The current naming scheme has been in place since May 2008, and I don't recall this issue coming up before. I definitely haven't heard anyone complain about the filename-vs-name issue before. IMO this is not an issue that comes up often enough to be worth fixing. Even if it were, a fix that didn't address temporary files would not be very helpful IMO.

comment:5 Changed 5 years ago by kovalev

Yes, fortunately enough the issue is very rare. Those torrents containing long names encoded in UTF-16 (some oriental character sets) are the most likely to be affected. This is how I've come across it recently. Anyway, it's definitely not of a top priority - as compared for instance to memory usage issues...

P.S. I should apologise for overlooking an important point. Indeed, simply replacing torrent name from metadata with a name of torrent file won't solve the problem if the latter is not available as in case of magnet link etc. Thus, current naming of temporary files should be kept in place - probably with some minor modifications. For instance, those temporary filenames could begin with a hash string. Then the name of the torrent could follow, with total string size truncated to the maximum allowed by the system. The unique filename could be generated in such a way with readability still being preserved at its current level.

Last edited 5 years ago by kovalev (previous) (diff)

comment:6 Changed 5 years ago by stub

  • Cc stuart.bishop@… added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Is there a work around for this issue? People are finding torrents that don't work for Transmission, but working fine for other clients.

This bug was opened upstream in Ubuntu:

comment:7 Changed 5 years ago by Harry

I have the same issue.

Just curious, is anyone else using an encrypted filesystem when getting this error? I think it's a mix of ... I get it mainly with UTF-16 style torrents, even though the actual characters are way under the filename limit.

Transmission doesn't handle it well, but I can't think of any way to properly handle it, sadly.

comment:8 Changed 5 years ago by jordan

  • Version changed from 2.22+ to 2.22

comment:9 Changed 5 years ago by konoame

Ah well, to quote a post
A file created on a NTFS system is allowed a filename consisting of up to 255 bytes of UTF-16 characters. Furthermore, some characters, mainly Chinese and Japanese, take up more space in UTF-8 than in UTF-16. I suppose that when the file is to be saved to my ext3 drive, the file name is converted to UTF-8, thus taking up more than 255 bytes, which is the filename limitation for ext3.

Yes, it is the limitation from ext3 filesystem. Fortunately, we can circumvent this by downloading the torrent to an NTFS volume. The problem now is transmission (I use the daemon) still complains the error even though I have set the download directory to the NTFS drive. I suspect this is because transmission puts the data to a temporary folder first (which is ext3, probably a cache folder in home directory), and it fails writing the temporary file. I think the error won't happen if the home directory is NTFS volume.

comment:10 Changed 4 years ago by agerwick

I've posted a temporary workaround here:

The issue seems to be related to encrypted volumes, and does not seem to be an issue on standard ext3 volumes. Hence there is no need to resort to anything as ugly as NTFS.

comment:11 Changed 3 years ago by OsmoHyttinen

This issues still seems to exist... On standard EXT4 WITHOUT encryption. It's indeed the "torrent name" NOT the file name of the torrent. This definitely needs to be fixed. Transmission 2.52 (13304). Kernel 3.2.0-4-amd64, #! 11, Debian 7.1

Last edited 3 years ago by OsmoHyttinen (previous) (diff)

comment:12 Changed 2 years ago by Nikoli

  • Cc nikoli@… added

comment:13 Changed 11 months ago by kip

I'm still getting this bug too with Transmission 2.84 (14307). I'm using an encrypted file system under Ubuntu 14.10. I've also noticed that if I restart Transmission after the error message appears, the torrent is deleted from the list of all torrents attempting to download.

Note: See TracTickets for help on using tickets.