On 3/04/2021 04:54, Bald Eagle wrote:
> No idea if this is related to the utf-8 issues.
> I was trying to answer someone else's question and came across this old post:
> 
>
http://news.povray.org/povray.advanced-users/message/%3Cweb.57a001e45c93b6e65e7df57c0%40news.povray.org%3E/#%3Cweb.57a0
> 01e45c93b6e65e7df57c0%40news.povray.org%3E
> 
> I don't recall it looking like that when it was originally posted ....

Interesting find. I've looked at the raw message on the NNTP server and 
it does in fact have the entity encoding present; e.g.

   x = & #961;cos(& #952;)sin(& #934;)
   y = & #961;sin(& #952;)sin(& #934;)
   z = & #961;cos(& #934;)

(Note I have spaced these out so they won't be classed as HTML entities 
and re-encoded by the server. The original had no spaces). This is how 
it would have appeared to NNTP users. The HTML entities are due to it 
being posted via the web interface and were sucked into the NNTP side as-is.

When re-displaying them, PHP's htmlentities() function is (correctly) 
escaping them as it assumes the input is not HTML formatted.

There is a way of telling htmlentities() to not re-encode existing 
encoded sequences, and I thought that may have been a default value 
change between the old and new PHP, but the docs don't say so, and 
google's cache from 4 March (so before the crash) shows it with the 
escaping also:

http://webcache.googleusercontent.com/search?q=cache:YzzVZteLENYJ:news.povray.org/web.57a001e45c93b6e65e7df57c0%2540news.povray.org

so I suspect it's probably been like that for a while. That said, 
though, it is an issue - either we ought to decode entity-encoded HTML 
before putting it into the NNTP server, or we need to not double-encode 
them when pulling out for display.

Given the data is already stored I can't change the first option, so for 
now I've turned on the second one (existing HTML encoding is passed over).

I'll need to have a think about what implications this might have going 
forward as I'm not sure it's the right fix (e.g. perhaps to only apply 
it to posts that were originally made via the web interface).,

-- Chris

Post a reply to this message

On 2/04/2021 12:05, Mike Horvath wrote:
> This part of the site is still down:
> 
> http://lib.povray.org/

I've had a stab at updating the lib.povray.org PHP code but have found 
it's going to be more work than I can allocate time to right now. I'll 
look at it later.

-- Chris

Post a reply to this message

wiki.povray.org is now back online, as is bugs.povray.org (not used for 
new bugs, I brought it back mainly for historical reasons).

The wiki had quite a few software changes, including a significant 
re-factoring of a custom extension we had, so if you spot anything out 
of place please LMK (in particular, the extensions for syntax 
highlighting and LaTeX markup have changed).

-- Chris

Post a reply to this message

in news:6072f98d$1@news.povray.org Chris Cason wrote:

> wiki.povray.org is now back online

Thanks!

Ingo

Post a reply to this message

Op 11-4-2021 om 16:00 schreef ingo:
> in news:6072f98d$1@news.povray.org Chris Cason wrote:
> 
>> wiki.povray.org is now back online
> 
> Thanks!
> 
> Ingo
> 

and thanks too!

-- 
Thomas

Post a reply to this message

in news:604ec2df$1@news.povray.org Chris Cason wrote:

> we've only lost about one 
> day of data

Over the years I've lost my newsgroup archive several times and currently 
don't maintain it. Could it be made available as a (always up to date) 
download in some way? 
I'd like to try and search it with SQLite's text indexing features.

Ingo

Post a reply to this message

Since someone is working on the server, when searching on Google, the 
wiki doesn't always show up in search results. For instance:

https://www.google.com/search?q=povray+average+pigment

Is there any way the server admin can demote the regular docs pages and 
promote wiki pages in results?


Thanks.

Mike

Post a reply to this message

Am 15.03.2021 um 03:10 schrieb Chris Cason:

> The NNTP server is the first to be brought back online and at the time I 
> post this is the only service running and publicly accessible. Posts 
> made here will eventually migrate to the web view once that's sorted and 
> back up; in the meantime only NNTP users will see this message.

Just trying to slowly get back up to speed, reading up on what's been 
happening while I wasn't looking, and found that Thunderbird refused to 
load a suspiciously large number of messages from back then, saying they 
didn't exist anymore. Tried to repair the index, and now all messages 
from 2019 seem to have been gone entirely (as well as a few months 
before and after).

Could that be related to the March 9 server failure, or was there an 
earlier separate problem that ate all the posts?

Post a reply to this message

On 26/05/2021 06:05, clipka wrote:
> Just trying to slowly get back up to speed, reading up on what's been 
> happening while I wasn't looking, and found that Thunderbird refused to 
> load a suspiciously large number of messages from back then, saying they 
> didn't exist anymore. Tried to repair the index, and now all messages 
> from 2019 seem to have been gone entirely (as well as a few months 
> before and after).
> 
> Could that be related to the March 9 server failure, or was there an 
> earlier separate problem that ate all the posts?

Any group in particular that is missing posts, or is it all?

For povray.general at least, posts seem to be there ...

   telnet news.povray.org 119
   group povray.general
   211 54252 3332 83275 povray.general selected

Estimated 54,252 articles in total, first article 3332 and last is 
83275. I'm able to retrieve both the first (from 1998) and the last 
(from today).

However that's not to say I know what exact requests Thunderbird is 
sending. If it happens again I suggest running tcpdump or wireshark on 
your end when you do the fetch so you can see exactly what Thunderbird 
is asking and what the server tells it in response. If you can send that 
to me I can take a look at it.

-- Chris

Post a reply to this message

Am 26.05.2021 um 02:06 schrieb Chris Cason:

> Estimated 54,252 articles in total, first article 3332 and last is 
> 83275. I'm able to retrieve both the first (from 1998) and the last 
> (from today).

That about matches the number of posts I'm seeing now, after rebuilding 
the index (54243; not sure where the difference of 10 is from). Before 
though, there were something like 70k articles for which Thunderbird had 
retrieved header information.

Posts as far back as 1998 are fine, as are recent posts. What I'm 
SPECIFICALLY NOT seeing anymore are any posts dating between 2018-10-07 
and 2020-04-18. And I know there were quite a lot, even a couple I had 
read just before rebuilding the index. Even a couple I had posted myself.

The same happens in each and every other group: Any posts from 2019 that 
are still in the index over here, but that I hadn't read yet, all just 
prompt a message saying they no longer exist. And if I rebuild the index 
of any group, all posts from 2019 - including ones I had read just 
minutes before - are just gone, without any trace whatsoever.

The web interface still seems to have them, for some reason. But the 
news server apparently doesn't.

> However that's not to say I know what exact requests Thunderbird is 
> sending. If it happens again I suggest running tcpdump or wireshark on 
> your end when you do the fetch so you can see exactly what Thunderbird 
> is asking and what the server tells it in response. If you can send that 
> to me I can take a look at it.

I have no idea what tcpdump or wireshark even do (I may be exaggerating 
here, but not by much), let alone how to run them on my Windows machine 
to put them to any good use.

Post a reply to this message