So many times, Like when Highwinds (the ONLY news servers
left on Planet Earth) are down right now, it would be
really great if we could copy the error logs from Dialog to
show our front end servers and convince them that somebody
at Highwinds is asleep.

There's no apparently way to cut & copy the log at any level
within the Dialog interface. And if you should manage to
find tghat log in your obscure programs folder (whcih is not
a Windows UAC folder), you of course can not open it and
send a report to your NSP because Dialog is already open and
using that file for write-only access.

Can we get a code fix for this in the next version?

Heh. Just kidding.

By the time I finish this complaint about a ludicrious
oversight that can't be fixed I hope that highwinds will be
back to normal... I just needed to burn some time bitching
<shrug>.

(are they even still called Highwinds? who in the fuck are
they nowadayz)?

-sw

On Fri, 1 Mar 2024 00:34:54 -0600, Sqwertz wrote:

> By the time I finish this complaint about a ludicrious
> oversight that can't be fixed I hope that highwinds will be
> back to normal... I just needed to burn some time bitching
> <shrug>.

Nope.
Highwinds fuckup again.

-sw

Sqwertz <sqwertzme@gmail.compost> wrote:

> So many times, Like when Highwinds (the ONLY news servers
> left on Planet Earth) are down right now, it would be
> really great if we could copy the error logs from Dialog to
> show our front end servers and convince them that somebody
> at Highwinds is asleep.
>
> There's no apparently way to cut & copy the log at any level
> within the Dialog interface. And if you should manage to
> find tghat log in your obscure programs folder (whcih is not
> a Windows UAC folder), ...

Dialog should not be installed under the C:\Program Files[ (x86)]
folders under Windows 7, and later. It isn't just UAC that protects
those folders. Permissions on those folders do not grant write access
to user processes. Program data is to be stored under the AppData
folders under a user's profile folder. Dialog needs to be installed
elsewhere, because it is too old to know about permissions on those
folders. I created a C:\Programs folder under where I put programs that
don't understand the C:\Program Files[ (x86)] folders have added
permissions to protect their contents. Only programs should be
installed there, not user data.

In File Explorer, right-click on one of the C:\Program Files[ (x86)]
folders, and choose Properties from the context menu. Look under the
Security tab. The Users security group does not have write permissions.
You could change permissions, but probably best not to mess with them.
Just put non-aware programs elsewhere.

> ... you of course can not open it and send a report to your NSP
> because Dialog is already open and using that file for write-only
> access.

I have Lockhunter installed which helps manage locked files (inuse,
write-only file handle). With Dialog running, I found a .log file that
was inuse, so it was locked, and I could not open it in Notepad nor copy
it. With Lockhunter, I can unlock the file (remove the write-only file
handle). Presumably Dialog might have problems continued writing to
this file thereafter, so exit Dialog to have it record to a new logfile,
or reuse the old logfile (since the only differentiation is by date
without a timestamp) with it opening the file with a write-only file
handle.

https://lockhunter.com/

Does Dialog actually delete the locked .log file when it exits? If not,
and since you're only interested in what is inside the .log file, not in
retaining the current Dialog session, why not exit Dialog, copy the .log
file, and restart Dialog when needed again?

> Can we get a code fix for this in the next version?

There is no next version of Dialog. It was abandoned back in 2002 with
a bugfix in 2005 (which you had to remove since it had a bug). The
latest version of Dialog you should be using is 2.0.15.41 (beta 38).
There will never be a later version unless someone somehow finds the
source code and takes up the dev work.

> Heh. Just kidding.

Heh, just informing.

> By the time I finish this complaint about a ludicrious
> oversight that can't be fixed I hope that highwinds will be
> back to normal... I just needed to burn some time bitching
> <shrug>.
>
> (are they even still called Highwinds? who in the fuck are
> they nowadayz)?

I don't remember Highwinds ever permitting direct end-user access. You
don't get an account at Highwinds to which you connect your end-user
NNTP client directly to their servers. They are one of about half a
dozen Usenet backbone providers (some of which do sell direct user
access, like Giganews), and resell their services to other Usenet
providers, so it is that someone else you use for Usenet access.

https://newsgroupservers.net/usenet-service-back-end-providers/usenetserver_newshosting_highwinds_review/
"Highwinds doesn’t sell directly through their own name. Instead, access
to their systems is done through other companies that buy from them and
re-sell to end users."

You're using a reseller of Highwinds that you did not identify, so
contact them. Their server being down or unresponsive does not mandate
all of Highwinds is also down. Considering the size and services of
Highwinds along with their merger with StackPath, I very much doubt all
of Highwinds ever goes completely down.

https://en.wikipedia.org/wiki/Highwinds_Network_Group
https://en.wikipedia.org/wiki/StackPath

You're posting here using Blocknews.net which is hosted at FDCSERVERS,
not Highwinds. You didn't identify your Usenet provider with which
you're having problems, and I doubt as an end user that you are directly
using Highwinds. A Usenet provider being down that resells (hosted at)
Highwinds does not mandate all of Highwinds is down. Eternal-September,
and others, are hosted at Hetzner in Germany, but ES being down does not
mean all of Hetzner is down, or even the other Usenet providers hosting
at Hetzner, just the hosted server for ES at Hetzner is down. The
hosting provider often does not allocate manpower to directly monitor a
hosted server. The admin of that server has to monitor, detect, or be
notified of a problem, and then request the hosting service perform
repairs if the admin cannot do so remotely.

Did you try to contact whomever is actually your Usenet provider to
report an outage?

On Fri, 1st Mar 2024 00:34:54 -0600, Sqwertz wrote:

> There's no apparently way to cut & copy the log at any level
> within the Dialog interface.

What's wrong with: Settings -> Show Status Window -> Log Tab?
You can use right mouse button to "Copy to Clipboard".

To get the most information, I'd suggest to first "Clear" the Log,
set the Log level to 0, execute the action that fails once (like
retrieving 1 message body or new messages for 1 group), then set
the Log level back to a reasonable 3 and at last copy the Log content
to the clipboard. I'd suggest going through the copied Log information
inside a text editor and delete any irrelevant or personal information
before sending it to your provider. (All functions mentioned, like
"Clear the Log" can be found in the right mouse menu for the Log Tab.)

Please note: If you use an SSL proxy like sTunnel, the relevant
information for your provider may be inside the sTunnel log file.
So you might need to check this, too. You can access the sTunnel
Log from right mouse menu of the tray icon.

HTH.
Bernd