Minor Bug / Oddities when parsing blocklists

[Altair]

All behaviour tested with 1.9.1 on OSX 10.5.
I ran into a minor bug (?) when playing around with the ipfilter functionality.
When adding a line like:

# someting:foo-bar

to an IPfilter filter, Transmission apparently tries to import it (I guess because of the ":$string-$string2" pattern), even if it's a comment line and could be discarded anyway.

In the log it shows up as:

"blocklist skipped invalid address [foo]"
"blocklist skipped invalid address [bar]"

Now if a blocklist contains a valid range ("$name:$IPv4.start-$IPv4.stop") that is contained in a comment line, Transmission apparently (judging from the number of lines/entries mentioned in the log) adds it anyway. This behaviour is unintuitive (at least from a users perspective), and should be reconsidered.

Another minor bug:

If a blocklist contains a line with a trailing space (didn't test other whitespaces) like:

"$name:$IPv4.start-$IPv4.stop "

instead of a proper

"$name:$IPv4.start-$IPv4.stop"

the log shows an error:

"blocklist skipped invalid address [$IPv4.stop ]"

But it also claims that the line is added to the .bin file (my testcase contains two lines, one malformated):

"Blocklist "test.bin" updated with 2 entries".

Unfortunately I don't know how to extract the information about the blocked ranges in the .bin file, so maybe the comments don't get added and the malformated ranges make it to the .bin file, but I thought some developers might clarify the issue or look into it.

[Jordan]

All behaviour tested with 1.9.1 on OSX 10.5.
I ran into a minor bug (?) when playing around with the ipfilter functionality.
When adding a line like:

# someting:foo-bar

to an IPfilter filter, Transmission apparently tries to import it (I guess because of the ":$string-$string2" pattern), even if it's a comment line and could be discarded anyway.

Now if a blocklist contains a valid range ("$name:$IPv4.start-$IPv4.stop") that is contained in a comment line, Transmission apparently (judging from the number of lines/entries mentioned in the log) adds it anyway. This behaviour is unintuitive (at least from a users perspective), and should be reconsidered.

I haven't seen any documentation that says a # denotes a comment line in the bluetack file format. Where are you getting this information from?

[Altair]

All behaviour tested with 1.9.1 on OSX 10.5.
I ran into a minor bug (?) when playing around with the ipfilter functionality.
When adding a line like:

# someting:foo-bar

to an IPfilter filter, Transmission apparently tries to import it (I guess because of the ":$string-$string2" pattern), even if it's a comment line and could be discarded anyway.

Now if a blocklist contains a valid range ("$name:$IPv4.start-$IPv4.stop") that is contained in a comment line, Transmission apparently (judging from the number of lines/entries mentioned in the log) adds it anyway. This behaviour is unintuitive (at least from a users perspective), and should be reconsidered.

I haven't seen any documentation that says a # denotes a comment line in the bluetack file format. Where are you getting this information from?

Phoenix Labs implementation recognizes comments, as mentioned in their Wiki. There never was an official specification for the P2P file format, granted, but as the parser in Peer Guardian 2 treats "# " as comment indicators and other blocklist providers use comments in their list, maybe Transmission could do so as well. Just a suggestion, though.