Unable to save resume file слишком длинное имя файла
Permanently about 500-1000 torrents paused by daemon with status "Unable to save resume file: Too many open files".
settings.json attached
Вложения (1)
Download all attachments as: .zip
История изменений (11)
Changed 9 лет ago by gatilisk
comment:1 Changed 9 лет ago by jordan
Also, props for seeding 4500 torrents.
comment:2 Changed 9 лет ago by gatilisk
comment:3 Changed 9 лет ago by cfpp2p
paused again with status "Unable to save resume file: Too many open files
I don't know if this will be any help but I had a similar problem once and don't remember exactly how it was resolved for me. During the interim I used the following code which adds the 'bool was = tor->isStopping;' section at the end of:
This prevents the torrents from pausing unless they are intentionally stopped and eliminated a lot of grief for me. With this the torrents will continue but really don't save the resume file! Sorry, can't exactly remember how I fixed the problem's cause but I still carry this code with no ill effects.
comment:4 Changed 9 лет ago by x190
From attached settings.json: "peer-limit-global": 40240,
Default is 240 and open file limit including peer connections is hard-coded to 1024. Set it to less than 1024 (say 800 or less) and try again.
Jordan and livings124: Why isn't the upper limit made clear in the documentation and the [Mac Client] interface? For example, the Mac Client r13629 will accept values up to 3000 for 'Global maximum connections' , but we never want more than about 800-900 as we need room for quote 'comment:2 100-200 of them are file descriptors'.
comment:5 следующий: ↓ 8 Changed 9 лет ago by jordan
A few random thoughts.
- I'd be surprised if transmission kept more than FILE_CACHE_SIZE (32) files open for local data.
- open-file-limit has been deprecated for awhile and is not used in the current codebase. It doesn't matter whether its value is 100 or 200000.
- cfpp2p's patch seems more like a band-aid for keeping Transmission limping along even after there are too many open files. it's kind of a clever idea for using in the interim until the problem's tracked down, but I'd hate to use it in production.
- x190's got a fair point about the peer limits. It's probably because the GUIs were in place before the fd limit was locked to 1024. x190, please make a separate ticket for that GUI issue.
So with that in mind. from the information given so far, it looks like most of these are IPv4 connections not in CLOSE_WAIT, but I'm not sure where to go from there. Does anyone have any thoughts on that?
comment:6 Changed 9 лет ago by x190
Hi Jordan: I think we've gone over this before! :)
man getrlimit RLIMIT_NOFILE The maximum number of open files for this process.
Setting max global peer limit to FD_SETSIZE is useless.
Total of peer sockets + FILE_CACHE_SIZE(32) + all other open files for this process must be
Имя файла действительно очень длинное.
У меня убунта 12.04. Файловая система ext4.
Понятно, что можно поискать другие источники, другие торрент-клиенты или даже другие ОС.
Но хотелось бы понять, почему так. Ведь «в именах файлов можно даже делать абзацы»!
UPD Есть кто-нибудь с Убунтой 12.04? Потому что, как выясняется, такие проблемы только у меня.
wikipedia:
ext4:
Max. filename length 255 bytes (characters)
reiserfs:
Max. filename length 4032 bytes, limited to 255 by Linux VFS
Т.е. ограничение не FS, а VFS, т.е. другие операционные системы может быть спасут демократию в Нигерии.
edit: нет, не спасут. Вообще странная фигня какая-то: в NTFS ограничение те же 255 байт и как этот файл на винде работае не понятно.
Раздачу не смотрел, буду дома гляну.
На ubuntu 12.10 Transmission качает.
в NTFS ограничение те же 255 байт
Не байт, а символов в UTF-16.
qbittorrent скачал на ext3 debian6
в NTFS ограничение те же 255 байт
Nope. 255 двубайтных символов UTF16.
Вполне может быть, что ограничение не имени файла, а общей длины пути до файла. Попробуй качать поближе к корню.
Хотя это совсем странно будет.
Debain Wheezy AMD64 ext4, 2 Tb
оно же даже меньше 255 символов, в чем проблема?
xtraeft ★★☆☆ ( 16.04.13 15:45:25 )
Последнее исправление: xtraeft 16.04.13 15:45:52 (всего исправлений: 1)
Я это знаю. Качал вообще в корень — тоже самое.
Трансмишн скачал успешно в раздел NTFS, но (!) опять написал ошибку о «длинном» имени и невозможности сохранить файл, хотя сохранил всё прекрасно.
Ktorrent — тоже самое.
а если просто создать такой файл, например через текстовый редактор?
Копирую файл из NTFS раздела в корень — ошибка, имя файла слишком длинное.
Просто создаю тектовый файл с таким именем, без расширения — такая же ошибка.
Но если сократить имя до
Т.е. убрать вот это: ов - 2010
Файл создается и копируется.
Все правильно — в UTF16 получается что длинная имени 318 байт.
Убираем немного байтов и всё работает.
Вопрос: у тех, у кого работает — другая кодировка файловой системы что ли?
я на hfs+ проверял
Максимальная длина имени файла 255 символов (255 UTF-16 encoding units, normalized to Apple-modified variant of Unicode Normalization Format D)
а про ext4 пишут:
Максимальная длина имени файла 256 байт
У тебя путь какой, куда тащишь? Имя файла нормальное. Тоже трансмишн, тоже ext4, всё качается нормально.
Я сталкивался с точно такой проблемой. И тоже при загрузке книг (да на рутрекере очень странная политика на счет именования файлов).
deluge справится. Она кажется переименовывает файл с длинным именем и качает.
Про кодировку тебе рассказали, ещё transmission делает копию торрент файла и создает .resume файл с информацией раздаче. Их имена зависят от содержимого торрент файла + 16 символов на хэш.
Можешь использовать FUSE для папки transmission и раздач, там ограничение немного повыше.
Переименование в transmission пока только в git ветке.
Тем кто думает что 255 байт хватит всем - позавчера хотел скачать серию , а там название + название серии уже 188 байт(на русском было бы 347 байт), скачал другой рип.
Ты выбрал «шифровать диск» при установке? Это уменьшает максимальную длину имени с 255 байт до примерно 140-146.
Debian, ext4, кодировка пути по умолчанию. Файл нормально скачался с помощью Tixati. И открывается тоже нормально.
Спасибо. Разгадали.
Ты выбрал «шифровать диск» при установке? Это уменьшает максимальную длину имени с 255 байт до примерно 140-146.
Та же проблема была вот сейчас.
Решил тем, что сохранил книгу на флешку, сформатированную в NTFS.
reiserfs лучше, и нифига ты не решил. Transmission скачает, но не сможет сохранить состояние раздачи и будет выкидывать ошибку.
Если, конечно, у тебя не зашифрован только каталог загрузки и проблема ещё и в этом.
В конфиге поменял только папку для скачивания и umask выставил на 0. Папку для неоконченных торрентов включал и выключал - не помогает.
В принципе трансмиссия мне не критична, пробовал rtorrent - слишком много костылять нужно. Но если кто-то посоветует более адекватный клиент без гуев и демоном буду благодарен.
пробовал rtorrent - слишком много костылять нужно
//У меня в конфиге umask почему-то 18.
umask я поправил на 0, я ж пишу - на старой системе было 18, но были очень странные права на файлы.
Костылять рторрент нужно до состояния демона. Нужно писать свой rc скрипт, а мне банально лень :)
ВИдел, но оно стартует в скрин, но зачем? есть детач. Я не пользуюсь скрином, максимум - тмукс. Короче костыли :)
Конфиг в хомяке поправь, оно не из /etc берёт.
Угу, ясно. Подожди, когда ошибка твоя исправится.
И если ты больше ничего не менял в transmission-daemon, то он у меня работает с umask 18.
Я знаю, в /etc/defaults поменял настройки, теперь он из хомяка берет.
Ну сейчас я поставил на 18 и перезапустил - ошибка на месте. Разве что обрывается закачка после 50-100Мб.
Опция incompete-dir используется?
пробовал и с ней и без нее - ничего не меняется
Error: Unable to save resume file: No such file or directory"
А директория resume есть?
директории такой нет. Но почему она должна быть?
Судя по гуглу это просто стандартная ошибка
Да, спасибо. Я параллельно сам разобрался - поковырял /var/ и нашлел там таки resume и понял, что теперь-то папка конфигов лежит не в варе, а у меня в ~/.transmission - создал там подпапку resume
посмотрю - если не отвалится, значит все правильно сделал :)
Еще раз спасибо, что натолкнул на мысль о resume
И, увы. Все опять упало.
Но, кажется, путь правильный
Вообще, я хз, может он пытается продолжать закачивание торрентов после паузы или остановки. Тем не менее, у меня и umask 18 и директория resume есть и все работает.
Пересоздал права - в ~/.transmission/resume начал сохранять что-то. Надеюсь, теперь не отвалится. Кстати, скорость поднялась.
Я не пользуюсь скрином, максимум - тмукс.
Перепиши скрипт запуска для тмукса. Такой способ запуска удобен для последующего руления процессом.
If I try add magnet link via transmission-daemon web-interface - I got error "Error: Unable to save resume file: File name too long".
If I add torrent file, all ok.
Deluge torrent client works fine with same magnet link.
I think problem in long name of temporary torrent file, who made from magnet link.
OS: Linux (raspbian arm32), Transmission-2.92 (2.84 have same problem), FS: Ext4
Magnet link for test: [censored]
The text was updated successfully, but these errors were encountered:
mikedld commented Jan 2, 2017
That's a good question. Suppose the link should've pointed to legal content in the first place.
cfpp2p commented Jan 4, 2017
one-quaker commented Jan 4, 2017 •
This magnet link have same problem. Thank you cfpp2p
screenshot
Hukuta commented Jan 7, 2017
"Error: Unable to save resume file: File name too long" is a popular problem for me.
I can't download some files with transmission, but with utorrent I can download same files to the same location (via virtual machine with windows and shared folder).
Hukuta commented Jan 16, 2017 •
What tool? How to use?
uTorrent saves this file in windows to same location without any problems, why transmission can't?
one-quaker commented Jan 16, 2017
And deluge saves without any problems. Why transmission? - it's a good question
cfpp2p commented Jan 16, 2017
v6 commented Mar 4, 2017
// , I can confirm I have this, too.
pik commented Apr 29, 2017
Same issue, I don't seem to be able to rename the file on opening a magnet-link (properly this error should prompt for a rename or something of the like?)
v6 commented May 1, 2017
// , Has anyone tested the work around that @cfpp2p proposed?
cfpp2p commented May 8, 2017
@v6 It is and has been working perfectly for me without issue.
pabloab commented Jun 5, 2017 •
pik commented Jun 5, 2017
I believe this might happen due to use of non-standar encodings such as KOI8R in the torrent name.
apolukhin commented Jul 7, 2017
This issue happens annoyingly often. Are there any plans to fix it?
v6 commented Jul 7, 2017
// , Seems like it could potentially be easy enough for someone to fix if they're familiar with the system.
On Fri, Jul 7, 2017 at 12:00 PM, Antony Polukhin ***@***.***> wrote: This issue happens annoyingly often. Are there any plans to fix it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
kov-serg commented Jul 24, 2017 •
I have the same problem today on my Ubuntu 14.04.
I have to find out reason. So get source
mkdir tr && cd tr
apt-get source transmission-gtk
And find error grep 'Unable to save resume file' -R .
Error message is in transmission-2.82/libtransmission/resume.c
It calls getResumeFilename from the same file
So the solution is to modify tr_metainfoGetBasename
let modify file transmission-2.82/libtransmission/metainfo.c
from
I assume utf8 encoding. This limit internal names to 32+17 chars or about. Limit is defined in name_max constant.
then ./configure && make
You can test it running from transmission-2.82/gtk/transmission-gtk
But you have to remove ~/.config/transmission directory or convert names into new scheeme.
Now it downloads any file without problems.
pabloab commented Jul 24, 2017
Hi @kov-serg,
v2.82 of Ubuntu 14.04 is pretty old. Seems you are talking about this lines on master branch. Could you please made a pull request against current source code? Or at least attach a patch file to this issue. Probably this could improve chances of having tested and added to the main source branch.
Thanks!
kov-serg commented Jul 24, 2017 •
Ununtu 14.04 is work well and I see no reasons to change it on something else.
Here is git diff
kov-serg commented Jul 24, 2017 •
here is script to convert old ~/.config/transmission files
In ~/.config/transmission directory
conv.lua
and then bash rename-script.sh
cfpp2p commented Jul 25, 2017
We don't need to filter the torrent name for Cyrillic characters or such. The name length should only be limited to 255. This way we won't need to convert .config files. Tested with @kov-serg Zelezko2009.torrent (and others).
kov-serg commented Jul 25, 2017 •
You can set name_max to 219 but I see no reason to have such long names. I use 32 because it looks sufficient in mc.
There is a hash and name could be removed at all. But it could help if you try to find something by hands (but I see no one try). You may create special function to shorten names and convert them into something short but you have create something to migrate from old version to new and backward.
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.
История изменений (13)
comment:1 Changed 11 лет ago by kovalev
- Краткое описание изменён с Better handling of long filenames на Better handling of long torrent names
comment:2 Changed 11 лет ago by jordan
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 11 лет ago by kovalev
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 11 лет ago by jordan
. so 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 11 лет 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.
comment:6 Changed 11 лет ago by stub
Is there a work around for this issue? People are finding torrents that don't work for Transmission, but working fine for other clients.
comment:7 Changed 11 лет ago by Harry
I have the same issue.
Transmission doesn't handle it well, but I can't think of any way to properly handle it, sadly.
comment:8 Changed 11 лет ago by jordan
comment:9 Changed 11 лет ago by konoame
Ah well, to quote a post
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 10 лет ago by agerwick
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 9 лет ago by OsmoHyttinen
comment:12 Changed 8 лет ago by Nikoli
comment:13 Changed 7 лет 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.
Читайте также: