I think Phex has a couple of lists stored in the jar file. I'm not sure just yet how it is working with them. Frostwire looks like it needs to be stripped down and cleaned up before it is tweaked too much. Thanks for the input! |
Maybe it can be tricked in some way, I suppose. Maybe using read-only attribute or modifying the dns of the site that it use to check the hash. Currently I don't have time but when I have more time I can create a modified Frostwire if it is possible. I have also the intention to create modified installers of many died P2P apps with support for one click update of the hostiles from GWC link without any executable. For live P2P apps they can add support themselves if they want once the "standard" is finalized. |
I have also tested the other blocklists and unfortunately they have more errors. Sorry to bring you more work. Lite without Japan block: Code: Start IP do not match. Code: Start IP do not match. Code: Start IP do not match. |
The lists have the MS newline character (^M) after every entry , but are missing the unix newline character (\n) after some entries. Maybe java doesn't care and the (^M) newline character is enough. Then the only problem would be non-java and non-MS systems/apps (Gtk-G on Unix) unless they have it coded to accept the MS newline on Unix builds. It is a real easy fix. If you need any help with that let me know. Just replace all "^M" with "\n" then all "\n\n" with "\n" then all "\n" with "\n^M" or "^M\n" (or something like that). I'm not sure it there is a standard for which one is to preceed the other. |
Well, if you use Notepad++ it have a function that do line-ending conversion in one click. I'm not sure what do you mean with "^M", but it is "\r" (the Mac line-ending). There are: Windows (\r\n) Linux (\n) Mac (\r) |
Quote:
I noticed that everytime it has a one newline character it is missing the other. So some entries are also missing the MS newline. |
The files contain both Mac and Linux newlines (they are both single); only Windows has double newline for every line. |
1 Attachment(s) Many thanks for people to point out errors. Embarrassing how many I've made over time including recently. :o The 192.52.x.x range I felt it might be best to get heavy with. 192.52.128.0/17 since all ranges are either Corporate Business or Government allocated. That range has had a bad history. Only possible ill-effect I could see is a College falls within that range. :p So which EOL format should I use? I vaguely recall reading 'somewhere' in gnutella docs (perhaps program commentary) about these differences & what you should probably choose to do to reduce possible problems. I presume this is the operation in question: Attachment 6863 It appeared to be taking a notable time to complete a test run of the operation on the full hostiles using the Unix/OSX format. Oops that seemed to cause problems. |
The Windows EOL (\r\n) should be avoided because it increase the size of the file. The old Mac EOL (\r) is almost extinct nowadays I think. I usually use the Unix EOL (\n), the most used I think. But we should test if it work correctly in all clients. |
Quote:
Quote:
Do not worry about errors, you work is impressive; with those big files it is normal to make mistakes. I have noticed also that there are empty lines. I have converted EOL to Unix and removed empty lines (other errors are still here): https://www.mediafire.com/folder/gcjrm0cthd7qx/ |
All times are GMT -7. The time now is 04:17 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.