cannot create TracLinks to attachments with number sign in file name

[jhn@…]

attachments with the number sign (#, also referred to as hash mark or pound sign) can be uploaded properly into trac, and the link generated in the Attachments section of the ticket works properly.

however, i cannot create TracLinks to the file.

attachment:attachment#1.txt

attachment:attachment#1.txt

attachment:'attachment#1.txt'

attachment:'attachment#1.txt'

[attachment:attachment#1.txt]

attachment#1.txt

[attachment:'attachment#1.txt']

attachment#1.txt

this is important for us because we document everything the client sends us, including file attachments, which sometimes come named with the number sign.

[jhn@…]

example of file with number sign in its name

[Christian Boos]

The following forms:

[attachment:'attachment#1.txt']
attachment:'attachment#1.txt'

have to be fixed.

[Christian Boos]

#9043 was closed as duplicate of this ticket. Indeed, this happens for any link resolver.

The fix for this is not immediately obvious, it might require quite some work and behavior change of the links (so that %\d\d sequences get recognized and unquoted at the proper time).

Tentatively putting back to 0.12.

[Remy Blank]

This is indeed tricky. By the time the link data arrives in _format_link(), it has been unquoted, and it's not possible anymore to differentiate between "attachment#1.txt" and attachment#1.txt.

Then again, we currently don't support parameters and fragments for quoted links, e.g. attachment:"attachment.txt"?format=raw doesn't work, whereas attachment:attachment.txt?format=raw works (the fragment is stripped, though, probably an oversight).

I don't think that escaping and unescaping names at various locations is the right approach. How about changing the parser to accept the syntax ns:"resource_name"?params#fragment and splitting the parameters and fragment in Formatter._lhref_formatter() (and passing them to the link formatters), and if the link is unquoted, not consider any ? or # to be parameters or fragments? The result would be:

Link	id	params	fragment
attachment:attachment?param#1.txt	attachment?param#1.txt
attachment:"attachment"?param#1.txt	attachment	?param	#1.txt

The drawback is that it would break links like wiki:WikiStart?format=txt that currently work. That's probably unacceptable.

I'm going to try and find even another alternative.

[Remy Blank]

There doesn't seem to be a simple, backward-compatible solution for this issue. So currently, the advice is "avoid using # in attachment names".

The non backward-compatible fix will be done in a next major version.