Skip to content
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

Closed
Tharn opened this issue Oct 13, 2016 · 24 comments
Closed

[2.92 x64 daemon W8.1] Special character issues #61

Tharn opened this issue Oct 13, 2016 · 24 comments

Comments

@Tharn
Copy link

Tharn commented Oct 13, 2016

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.

@mikedld
Copy link
Member

mikedld commented Jan 13, 2017

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.

Related to TRAC-4160, TRAC-4753.

@Tharn
Copy link
Author

Tharn commented Jan 14, 2017

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.

@hhrhhr
Copy link

hhrhhr commented May 30, 2017

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.

@Sargrak
Copy link

Sargrak commented Nov 6, 2017

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.

@Tharn
Copy link
Author

Tharn commented Nov 6, 2017

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.

@jescin
Copy link

jescin commented Nov 12, 2017

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.

@jescin
Copy link

jescin commented Nov 26, 2017

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\ ):

Option Explicit

'define location of Transmission client
Dim sTrnsLoc:		sTrnsLoc = "C:\Program Files (x86)\Transmission Remote GUI\transgui.exe"

'define delimiter to split magnet link into parts
Dim sDelimit:		sDelimit = "&"

'define headers for the sections in which replacements are to be made
Dim aReplHdr:		aReplHdr = Array("dn=")

'define text strings for replacements in specified headers above; even number of items needed; item 1 replaces 0, 3 replaces 2, etc
Dim aReplTxt:		aReplTxt = Array("%3A", "")

'define text strings for global replacements at the end before submitting final text to the copy buffer; even number of items needed
Dim aReplAll:		aReplAll = Array("%", "^%",_
									 "&", "^&",_
									 "<", "^<",_
									 ">", "^>",_
									 "|", "^|",_
									 "'", "^'",_
									 "`", "^`",_
									 ",", "^,",_
									 ";", "^;",_
									 "=", "^=",_
									 "(", "^(",_
									 ")", "^)",_
									 "!", "^!",_
									 "^", "^^^",_
									 """", """"""_
									)

'grab raw magnet link from memory, and split using provided delimiter
Dim sRawLink:		sRawLink = WScript.Arguments(0)
Dim aRawLink:		aRawLink = Split(sRawLink, sDelimit)

'dimension variables for array looping
Dim i, j, bMatch

'loop through split magnet link array...
'test to make sure each item matches to an entry in aReplHdr, then run through replacements in aReplTxt
For i = 0 to UBound(aRawLink)
	
	bMatch = False
	For j = 0 to UBound(aReplHdr)
		If Left(aRawLink(i), Len(aReplHdr(j))) = aReplHdr(j) Then
			bMatch = True
			Exit For
			End If
		Next 'j
	
	If bMatch = True Then
		For j = 0 to Ubound(aReplTxt) Step 2
			aRawLink(i) = Replace(aRawLink(i), aReplTxt(j), aReplTxt(j + 1))
			Next 'j
		End If
	
	Next 'i

'reconstitute link from array
Dim sRepLink:		sRepLink = Join(aRawLink, sDelimit)

'loop through global replacements, necessary to pass cleansed string in command line echo
For i = 0 to UBound(aReplAll) Step 2
	sRepLink = Replace(sRepLink, aReplAll(i), aReplAll(i + 1))
	Next 'i

'define shell object
Dim objShell:	Set objShell = WScript.CreateObject("WScript.Shell")

'add link to copy buffer
objShell.Run "cmd.exe /c echo " & sRepLink & "| clip", 0, TRUE

'open Transmission client
objShell.Run """" & sTrnsLoc & """", 0, FALSE

'unset objects to prevent memory leaks
Set objShell = Nothing

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):

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Magnet]
@="Magnet URI"
"Content Type"="application/x-magnet"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\Magnet\DefaultIcon]
@="\"C:\\Program Files (x86)\\Transmission Remote GUI\\transgui.exe\",0"

[HKEY_CLASSES_ROOT\Magnet\shell]
@="open"

[HKEY_CLASSES_ROOT\Magnet\shell\open]

[HKEY_CLASSES_ROOT\Magnet\shell\open\command]
@="\"wscript.exe\" \"C:\\Program Files (x86)\\Transmission Remote GUI\\ColonCleanser.vbs\" \"%1\""

@hhrhhr
Copy link

hhrhhr commented Dec 10, 2017

@Tharn

there is no safe and backwards compatible way for torrent title / folders / files to be transformed for the file system.

How is it "no"? You only need to replace the forbidden characters when writing files / directories without changing the data of the torrent file.
In Windows, you can not create a torrent with a colon in the file / directory name, since this can not be done in the OS itself. Therefore, we are talking only about one-way conversion.
And now even if you change the destination directory without the forbidden characters in its name, temporary files still try to be created with a colon in the name, which causes the download to stop every few minutes. (see #301 )

@Tharn
Copy link
Author

Tharn commented Dec 11, 2017

I'm agreeing with you, probably pinged the wrong person there

@jriker1
Copy link

jriker1 commented Apr 14, 2018

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

@Tharn
Copy link
Author

Tharn commented Sep 27, 2018

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.

@danfiscus
Copy link

danfiscus commented Nov 18, 2019

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.

@danfiscus
Copy link

@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?

@Statick
Copy link

Statick commented Feb 2, 2020

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

@Zednine9
Copy link

Zednine9 commented Feb 7, 2020

please fix this issue... anyone?? :)

@danfiscus
Copy link

danfiscus commented Feb 7, 2020

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...

@Tharn
Copy link
Author

Tharn commented May 5, 2020

Good workaround.
The issue is just as simple without 'hacky' solutions like these:
Just have Transmission strip invalid characters from filenames and directory names. Keep them in the torrent name. Done.

This is the one big issue keeping Transmission on Windows from being rock solid. Please consider putting a fix together for 3.0.

@mikedld
Copy link
Member

mikedld commented May 5, 2020

I think this was fixed as part of #294 (see 99033b0). Feel free to test current nightly and report back.

@brian-duffy
Copy link

The current nightly fixed this issue for me on W10 - thanks 👍 👍

@Tharn
Copy link
Author

Tharn commented May 9, 2020

Will close it as soon as I can confirm in the upcoming stable version, if that's alright with everyone.

@mikedld mikedld added this to the 3.00 milestone May 9, 2020
@rzcat
Copy link

rzcat commented May 13, 2020

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😰

@Tharn
Copy link
Author

Tharn commented May 13, 2020

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!

@Tharn
Copy link
Author

Tharn commented May 22, 2020

Closing for now. Assume fixed.

@Geniusssmit
Copy link

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests