-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.92 x64 daemon W8.1] Special character issues #61
Comments
Windows builds are fully Unicode (at least I hope so). Thus, "è" should be no problem unless it's not encoded in UTF-8 (which might well be the case). Torrents with Russian and Chinese characters in names worked fine in my tests. If the torrent you had an issue with is public and legal, feel free to attach it here. Otherwise, we'll fix it when we'll fix it. As for ":", this character (among few others) is forbidden in file and directory names by Windows itself and so needs to be somehow transformed (replaced with allowed character). Names present in torrent metadata are said to be purely advisory, but currently there is no functionality to make those transformations automatically in safe and backward-compatible way. |
Just tried it. I can comfirm that a torrent with French symbols (à, ô, é) works fine. Let's assume that the one with an apostrophe was encoded differently. I don't have it anymore, unfortunately. |
Sorry, but I do not quite understand why the label "enhancement" is set and not a "bug"? This is not only Windows specific issue, FAT/NTFS volumes can be mounted in Linux too. |
I've been hit with that problem too. I can propose editing the filename/filename part of the magnet link, removing the colon, as a workaround. |
mikedld mentioned there is no safe and backwards compatible way for torrent title / folders / files to be transformed for the file system. I would suggest that all forbidden characters are simply stripped for the file system, i.e. removed with no empty space, and kept as-is in metadata. A double point could also be replaced by a dash, but why go through the trouble of making particular rules for this when it just has to be coherent? Since torrent title / folder / file names are all stored accurately in the torrent metadata, I don't see the functional difference between two-way and one-way transformation here. If the rule is uniform, repeatable and well-handled by transmission, it should write to and parse from file system just the same? Files and folders should always have sensible names anyway, since they originate from a file system. It's mostly the torrent tiles that are wild and are a problem right now. |
I have this issue as well, and happen to have the problem in Linux (because my target is an NTFS volume). I can work around the problem by editing the magnet link manually as suggested above. Inconvenient, but it still works. I also agree that this seems better categorized as a bug rather than as an enhancement. |
So, in my setup I have Transmission Remote GUI on several Windows machines pointed at a Linux box running the Transmission client. As I said before, the Linux box is writing to an NTFS volume (it's an old setup, don't ask me why I did it this way, honestly I should just redo the volume as ext 3 or 4, but I digress...). Invariably, the colon character is a problem for me in filenames. As such, I wrote a vbscript to help me get around the problem (I called it ColonCleanser.vbs lol); it simply strips colons from the filename portion of magnet links before submitting them to Transmission. I accomplished this by 1) copying the script into C:\Program Files (x86)\Transmission Remote GUI\ on every Windows machine and 2) updating the registry on each to handle magnet links with said script. I've copied the script and registry entries from my setups below. If any of you try using it, I suggest reviewing the script and registry entries to be sure the locations in each match your setups, and edit as needed. Hopefully this helps others with other folks' NTFS issues. Here is the meat of the file ColonCleanser.vbs (create the file and copy it to C:\Program Files (x86)\Transmission Remote GUI\ ):
And here is the meat from my registry entry if you'd like to recreate it. Create any file with the .reg extension and copy the following code into it, then run it to update your registry (I suggest backing up your existing HKEY_CLASSES_ROOT\Magnet key before running this):
|
How is it "no"? You only need to replace the forbidden characters when writing files / directories without changing the data of the torrent file. |
I'm agreeing with you, probably pinged the wrong person there |
So have we determined that in windows if your Transmisison starts downloading magnetic links with colons in them that it will just sit and be stuck? I am using Sonarr for those familiar and maybe I can set to eliminate files with a colon in it but not sure how that work or what it will eliminate from my ability to download stuff. JR |
Double colon character still makes Transmission throw up and crash. Come on folks, please make a scheme for forbidden character transformations. This is a big deal. This fault excludes uncountable torrent files from working. |
I just want to bump this issue and ask if there has been any progress. This should absolutely be classified as a bug, and it does not just affect Windows users, it affects all users with NTFS drives as @jescin stated above. We know exactly what is causing this bug and we have numerous ways of fixing it, but nothing has been done in over 3 years. Tagging @ckerr because he seems to be doing a lot of excellent maintenance in this repo and I believe this should be taken care of. |
@mikedld You seem fairly active in this repository, this is a serious issue that is over three years old and as a member of this community that uses this software on a daily basis, I'm getting really tired of the lack of attention being paid to issues like this. Is there anything you can do to push for a fix of this? |
just abandoned another torrent because of a : in the filename this is a critical failure of the software and one that should be easily fixable (character replace with | for example), it's been an issue for an extremely long time and it seems odd that such an obvious bug would just be ignored for so long |
please fix this issue... anyone?? :) |
POSSIBLE WORKAROUND: If you find a torrent with a : in the file name, open it in Transmission using a magnet link, then manually edit the URL to remove %3A (this is the URL encoding for a colon symbol). Once the : character is removed from the magnet URI, the torrent should be able to add itself like normal and function. This means literally the only code needed to close this issue is a simple URI string checker that can remove invalid characters from a link. Hopefully something that simple is able to be fixed, but then again, this issue has been open for over 3 years... |
Good workaround. This is the one big issue keeping Transmission on Windows from being rock solid. Please consider putting a fix together for 3.0. |
The current nightly fixed this issue for me on W10 - thanks 👍 👍 |
Will close it as soon as I can confirm in the upcoming stable version, if that's alright with everyone. |
This issue is set to milestone 3.00. You are waiting for the upcoming stable version to confirm and close this issue, while v3.00 is waiting for this issue to be closed first😰 |
Yep, lol. I tried with transmission-3.00+-r20119f006c-x64, and as far as I can tell, torrents with ":" in the title load fine now. They tend to have different internal names so I have not seen a case where the ":" persisted until it was time to write a folder name, anyway. Would be interesting to see what happens then, or if it is possible. If you have a good example torrent for this, let me know! |
Closing for now. Assume fixed. |
It's not. I have torrent file with "[___e_摾_Y] ___ɂ____Ȗ__e_摾_Y" name, qbittorrent downloads it just fine but transmission shows an error "no such process" |
Hey,
I saw something about fixed symbols in the commits but I'm not sure if this covers all special characters and cases, so here goes. Feel free to close it otherwise:
In Transmission 2.92, running as a 64-bit daemon on Windows 8.1, I've had two instances of unusuable torrents. The program couldn't handle a ':' or 'è' in the torrent name and produced an item in the list that wasn't usable because of a resume error. It left over a file without proper extension in the Resume folder that I also had to delete manually after getting rid of the item in question with Shift+Del.
These also couldn't be fixed by hand after the fact. I had to resort to torrent files that didn't have these characters.
The text was updated successfully, but these errors were encountered: