Every once in a while Dialog gets corrupted
But that settings.ini file has to be repopulated with the Identities.
If I'm lucky, the repopulation of the identities works. But that's rare.
Most of the time the repopulation of identities doesn't take hold.
Why?
From experience I've learned the problem is not what is in the section between "[Identity0]" and "defstandardheaders" that matters, but the
problem is that it matters WHERE it's placed inside the settings.ini file.
On Thu, 28th Apr 2022 20:55:29 +0200, wasbit wrote:
Every once in a while Dialog gets corrupted
It shouldn't. Despite its age, corruption of the setup and/or database of Dialog is /not/ to be expected. Maybe there is some general problem, like
an unsuitable path of installation (UAC protected folder), an interfering
AV program, or sth. like that?
On Thu, 28th Apr 2022 20:55:29 +0200, wasbit wrote:
Every once in a while Dialog gets corrupted
It shouldn't. Despite its age, corruption of the setup and/or database of
Dialog is /not/ to be expected. Maybe there is some general problem, like
an unsuitable path of installation (UAC protected folder), an interfering
AV program, or sth. like that?
This had happened to me during plenty power outages/improper
shutdowns (while Dialog is idle) and when I've been downloading
hundreds of thousands of headers.
And check IdentitiesCount inside the [General] section.
From experience I've learned the problem is not what is in the section
between "[Identity0]" and "defstandardheaders" that matters, but the
problem is that it matters WHERE it's placed inside the settings.ini file.
Not really, AFAICT. Be careful, though, /not/ to insert a section with its settings in the midst of another section. And check IdentitiesCount inside the [General] section. Identity numbers are zero-based. So, if your maximum identity section is [Identity2], then you'd need to set above count to 3. Also be sure to keep the "name" values of the identities unaltered and without added spaces and the like. If you want to rename an identity, do
so in the Dialog GUI.
I have a tested sequence to repopulate the setup when Dialog gets
corrupted
As the last step of repopulating Dialog if I create an equal number of
dummy identities inside the Dialog GUI
then I close Dialog and swap out the separate text files [BR: containing
the backed up identity settings] into the settings.ini file with each identity in the exact strange places that they end up in the
settings.ini files, then it always works.
but my question here is what is the logic of where identities go inside
the settings.ini file?
If I understand correctly, you recreate everything from scratch? (Instead
of restoring a current backup.)
Not really. I make a full backup periodically because corruptions are frequent enough and you never know what got corrupted.
But I only pull out of that full backup the few files that are required for customizations to be recreated (such as a dictionary file).
If I understand correctly, you recreate everything from scratch? (Instead
of restoring a current backup.)
I'd rather suggest to keep a full backup of the Dialog folder and its subfolders (with the exception of "data") and replace it, whenever a substantial change in settings (like a new or altered identity) occurred.
The backup must only be created, when Dialog is not running, of course.
For the data folder, keep the backups (at least the latest) after running CompactDatabase.
Alternatively, you can do a full backup by copying it
at any time. (Again: Dialog not running, of course.) *Never* mix two different states of the data folder!! You'd break the database this way,
for sure.
After setup and/or database corruption, you'd get back to the latest
saved state quite easily. (Without any manual pre-configuration steps,
like setting up dummy-identities inside the GUI.
As the last step of repopulating Dialog if I create an equal number of
dummy identities inside the Dialog GUI
This step should have also created the correct setting of IdentitiesCount inside the [General] section.
then I close Dialog and swap out the separate text files [BR: containing
the backed up identity settings] into the settings.ini file with each
identity in the exact strange places that they end up in the
settings.ini files, then it always works.
Please note, that reference of an identity (to its folder and so on) in
the database is /not/ the number in the section name. (Like e.g. "3" for [Identity3]. The number just defines the sort order of the identities
inside the Dialog GUI. - Although the numbers ought to be continuous (starting by 0), overall, and must not be larger than IdentitiesCount
minus 1.
The pointer to the database folders is the "name" of the identity. If you pre-create the dummy-identities inside the GUI you /need/ to make their
names identical to the ones restored from your backup text files to the
last single character. Else, the connection of the identity to the
Dialog database is broken and your next crash is bound to happen soon.
but my question here is what is the logic of where identities go inside
the settings.ini file?
IMHO, the section order largely depends on creation/alteration time and therefore is (more-the-less) driven by chance. AFAICT, the placement of
each section is left to the Windows *.ini-file management functions.
If a section does not exist, it is inserted top-most by these functions.
If just a value inside an existing section is altered, the placement of
the section remains unaltered. Dialog seems(!) to write some settings
by replacing sections in whole. (= Deleting them and writing them anew.)
Depending on you altering here and there in the GUI, each of /these/
sections have a chance to end up top-most at any given moment. Altering existing identities, OTOH, has no such section-reordering effect. The
latest (by creation date and time) identity will be topmost of all identities. But there may be (one or more) arbitrary other sections
between each pair of identities, because of the process described above.
Nevertheless, the placement of a certain section inside settings.ini shouldn't matter the least to Dialog.
To clarify what I do is I periodically make a backup of the whole dialog directory and then when the original gets corrupted, then I delete that entire backup and then I re-install a new dialog and copy over the updated executable (like everyone does the first time they install dialog).
If I understand correctly, you recreate everything from scratch? (Instead
of restoring a current backup.)
Not really. I make a full backup periodically because corruptions are frequent enough and you never know what got corrupted.
But I only pull out of that full backup the few files that are required for customizations to be recreated (such as a dictionary file).
But if there's a better method to recover from corruptions, I'll learn it.
data contains most of the changes over time
and settings.ini can get corrupted (which was my most recent corruption).
For the data folder, keep the backups (at least the latest) after running
CompactDatabase.
I don't really know how compacting affects being able to copy back at a
later date.
Therefore I'm afraid to compact because I don't know if that makes it compatible or not but the real problem with copying back the entire data directory is I don't know which files got corrupted and they may be one of those data files that I don't need to copy over.
How does compacting help in terms of copying back files later?
But what if the settings.ini file is what got corrupted?
As the last step of repopulating Dialog if I create an equal number of
dummy identities inside the Dialog GUI
This step should have also created the correct setting of IdentitiesCount
inside the [General] section.
I realized my mistake in concluding wrongly that the POSITION of the identities mattered. It wasn't the position after all. It was that I was unaware of the GENERAL section in settings.ini which required a manual setting of the number of identities. That was all my fault.
I don't understand anything in that paragraph because I don't see any
folders that have anything to do with any identity (or even the number of identities).
40tude Dialog is completely self-contained. Some user scripts have been relying on absolute paths and therefore would need adjustment. Apart from this, the whole Dialog directory could be copied to whatever location
(even USB thumb drives) and successfully run from there.
That said, Dialog /must not/ be installed or copied into an UAC protected folder, like "C:\Program Files\". (It is possible to do so, but requires detailed manual adjustments.) A folder like C:\Portable\ would be okay.
Because of its portability, you can restore Dialog from a backup copy by simply deleting or renaming the folder of the defect installation and
copying the backup folder with its subfolders to the old and new location.
Do not mix parts of a backup into either a fresh or faulty installation
or into a restored backup from another time! Although most files will not
be problematic, settings.ini might and the whole content of the "data" subfolder /will/ result in faulty internal references.
data contains most of the changes over time
Data contains the whole Dialog group and article database. It /of course/ changes continuously over time. CompactDatabase can be used to clear the folder of deleted content. (Deleting a message inside Dialog just sets an internal marker in the database, but does not really delete anything.)
If you encounter problems with articles in a certain group, you can delete all articles, unsubscribe and run a CompactDatabase. Afterwards you can re-subscribe and call SampleHeadersFormGroup (Online menu) to refill the group from server. I never had the necessity to do so since the beginning, though.
and settings.ini can get corrupted (which was my most recent corruption).
Never had this, either.
The only situation, where settings.ini is likely
to get corrupted is by installing Dialog in an UAC protected folder.
In such a case (if the setup did not receive certain manual adjustments), two settings.ini exist and sometimes cancel each other out. (Reading from one, writing to the other.) One settings.ini would be the one of the Dialog folder. The other resides in the VirtualStore inside the "C:\Users" tree.
For the data folder, keep the backups (at least the latest) after running >>> CompactDatabase.
I don't really know how compacting affects being able to copy back at a
later date.
You /never/ *mix* the content of 2 "data" folders.
Delete or rename the
one to be replaced and copy the other from backup. It doesn't matter, if
the backup has another CompactDatabase state. The various internal pointers are self-contained inside "data". You just get an uncompacted state when restoring a copy of "data" created before (or by) CompactDatabase. Run CompactDatabase (again), and the database will (again) become smaller.
By restoring an older version of "data" you (of course) loose all changes
to the database that took place after creating the backup. But even if you are tempted to save some of these losses by mixing the backup with the most recent version of data (corrupted or not). Do /not/ give in! The probability of the database /not/ getting corrupted this way is small. (Although any problems might manifest themselves much later.)
Therefore I'm afraid to compact because I don't know if that makes it
compatible or not but the real problem with copying back the entire data
directory is I don't know which files got corrupted and they may be one of >> those data files that I don't need to copy over.
If a CompactDatabase runs successfully, the database should be intact.
(At least intact enough to be used.) Therefore, either the backup of the uncompacted "data_oldXX" folder or a fresh backup copy of the compacted "data" folder should be usable in later emergencies.
If only a certain group has problems, use the selective cleanup process described above.
Be sure to also save everything else (not only the "data" subfolder), whenever you add/change a server, an identity or the like. Otherwise
you'd loose access to those parts of the database.
How does compacting help in terms of copying back files later?
Apart from keeping the backup small, Dialog is not meant to be used as archive for huge amounts of messages. (Use Hamster or any other local
Usenet news server for such a requirement.) The more messages are stored inside the Dialog database (deleted or not), the longer takes each lookup. Long lookups increase the risk of sth. interfering, like an AV program suspicious of the long read time or certain database contents, a power outage, or any other reason.
Please note, CompactDatabase does not /compress/ the database files in
any way. It just removes deleted messages from storage and reorders the database structure according to your subscribed servers and groups.
But what if the settings.ini file is what got corrupted?
UAC problems with 2 different settings.ini (see above) aside: If Dialog worked well before closing, and it did not crash while closing, then your settings.ini should be okay to backup. (And to be restore later on, if
need should be.)
If you want to err on the cautious side: Keep /several/ backups from different times. Just be sure, these backups match your current server
and identity settings. Otherwise any current or backup "data" folder
will not match.
As the last step of repopulating Dialog if I create an equal number of >>>> dummy identities inside the Dialog GUI
This step should have also created the correct setting of IdentitiesCount >>> inside the [General] section.
I realized my mistake in concluding wrongly that the POSITION of the
identities mattered. It wasn't the position after all. It was that I was
unaware of the GENERAL section in settings.ini which required a manual
setting of the number of identities. That was all my fault.
IdentitiesCount should never be set /manually/.
You either restore a
complete settings.ini matching the current "data" subfolder. Then the IdentitiesCount and the identities themselves (aka their count as well
as their names) contained inside settings.ini should be okay. Or you
create new identities inside the GUI. This step not only writes values
into settings.ini, but also creates files and entries inside files in
the "data" folder. Both are linked by the /name/ fields of each identity. Defining or altering an identity name, therefore, is /only/ possible in
the GUI.
[Pointers from settings.ini into data]
I don't understand anything in that paragraph because I don't see any
folders that have anything to do with any identity (or even the number of
identities).
The pointers are not human-readable. The names of the identities appear somewhere inside the file of the whole list of (news)groups and folders
(= groups.stg). The position in this file is a pointer to the next files, where they are linked to (arbitrary) numbers, that link to the numbered database files. Within these files are other numbers, that point into
the files containing any messages from and to these identities.
Conclusion: Never mess with single files, but backup the whole Dialog
folder and all its subfolders. From "data" subfolder you can backup
later copies (= always the /whole/ subfolder), as long as you didn't
alter anything from server settings to identities. If you did, create
a new backup containing everything.
I'm not sure which of the dictionaries actually change as I don't know if american.adm is actually updated when new words are manually added by me.
I don't need the grouplist nor any of the actual messages inside the groups since they can be downloaded again from the servers (although I turn off purging so I may lose some of the oldest messages in any given newsgroup).
and settings.ini can get corrupted (which was my most recent corruption). >>Never had this, either.
I shouldn't call it a corruption. It's more like I accidentally hit some setting that just screws up everything inside of Dialog. The most recent 'something' was that I couldn't see messages that I knew were there.
They were hidden somehow.
It happened all of a sudden so I don't know what caused that.
You /never/ *mix* the content of 2 "data" folders.
But you have to if "something" inside the data folder got corrupted.
Don't you?
I'll try the suggestion of copying the entire data directory back at the
next Dialog corruption but that won't work if the corruption is outside the data directory. But I don't know where the corruption is of course.
I'm not sure which of the dictionaries actually change as I don't know if
american.adm is actually updated when new words are manually added by me.
It will not be altered. User added words go to the user dictionaries.
Just in case, do you know what is the purpose of alldsc.dss is?
The file alldsc.dss contains the whole list of group names and descriptions of all groups carried by all Usenet servers you set up in Dialog.
BTW, in switching over to Dialog I noticed I can't get the attribute to
work the way I am used to it working.
Using this attribution line
"%from%" wrote in message %message-id%...\n
I get this as a resulting attribution
"Bernd Rose <b.rose.tmpbox@arcor.de> wrote in message"
<news:18tsdrmhthtab$.dlg@b.rose.tmpbox.news.arcor.de>...
Not this
"Bernd Rose" <b.rose.tmpbox@arcor.de> wrote in message
news:18tsdrmhthtab$.dlg@b.rose.tmpbox.news.arcor.de...
From RFC850 - 2.1.7 Message-ID:
| The angle brackets are considered part of the message ID.
https://www.freesoft.org/CIE/RFC/850/10.htm
Do you know if Dialog can break the %from% & %full-name% apart?
Sort of like Dialog has all that power to break the date & time & day?
The variable %full-name% is the name part of the whole %from% address.
Apart from this, no further variants of these two variable are available.
It is theoretically possible to parse and alter the attribution line in
an OnBeforeSendingMessage script to break down and reformat attribution
in more detail. But, IMHO, that isn't really worth the effort...
I would like to post my recovery sequence though, to see if it can be improved. Should I post that recovery sequence here?
I do a compress every so often, but since I never delete anything,
that basically just serves a backup - unless Dialog keeps other
housekeeping info in there that it deletes during that procedure(?)
Dialog fresh install always chokes on the sheer number of
headers being downloaded even when I set the sockets to 1 (I'm not
sure if pulling headers uses more than one anyway).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 482 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 74:20:08 |
| Calls: | 9,572 |
| Calls today: | 3 |
| Files: | 13,666 |
| Messages: | 6,142,502 |