| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| faq:misc [2018/03/01 12:10] – Links to util:binkit changed to module:binkit digital man | faq:misc [2018/03/01 12:21] – old revision restored digital man |
|---|
| |
| :!: **Answer:**\\ | :!: **Answer:**\\ |
| In Synchronet, when a message is deleted, it is only flagged for deletion. The actual removal of "deleted messages" from message bases takes place during regularly scheduled message base maintenance (using the [[module:binkit]] utility). Normally, messages flagged for deletion will have a **DELETED** attribute displayed in the message header, if/when the message is displayed to a user. Messages flagged for deletion may be "undeleted", but only when they are visible to a user or sysop. | In Synchronet, when a message is deleted, it is only flagged for deletion. The actual removal of "deleted messages" from message bases takes place during regularly scheduled message base maintenance (using the [[util:smbutil]] utility). Normally, messages flagged for deletion will have a **DELETED** attribute displayed in the message header, if/when the message is displayed to a user. Messages flagged for deletion may be "undeleted", but only when they are visible to a user or sysop. |
| |
| There is a Synchronet configuration option, [[module:binkit]]->Message Options->Users Can View Deleted Messages, with three possible settings: | There is a Synchronet configuration option, [[util:SCFG]]->Message Options->Users Can View Deleted Messages, with three possible settings: |
| - Yes | - Yes |
| - No | - No |
| If the sysop wants deleted messages to appear to be immediately and permanently removed from the message base, they should set this option to "No". When this option is set to "Yes", all users with read-access to the message base will be able to view/read messages flagged for deletion. When set to "Sysops Only", this option will only allow messages flagged for deletion to be visible to system operators (sysops) and sub-booard operations (sub-ops). | If the sysop wants deleted messages to appear to be immediately and permanently removed from the message base, they should set this option to "No". When this option is set to "Yes", all users with read-access to the message base will be able to view/read messages flagged for deletion. When set to "Sysops Only", this option will only allow messages flagged for deletion to be visible to system operators (sysops) and sub-booard operations (sub-ops). |
| |
| Note: Deleted messages may still be viewed and undeleted using the [[module:binkit]] program and possibly other methods, until the deleted messages are actually removed from the message base during maintenance. | Note: Deleted messages may still be viewed and undeleted using the [[util:smbutil]] program and possibly other methods, until the deleted messages are actually removed from the message base during maintenance. |
| |
| ===== New User Feedback ===== | ===== New User Feedback ===== |
| "Require new user feedback" check-box. | "Require new user feedback" check-box. |
| |
| Or, set [[module:binkit]]->Nodes->Node 1->Advanced Options->Validation User to "0". If you | Or, set [[util:SCFG]]->Nodes->Node 1->Advanced Options->Validation User to "0". If you |
| want your new user validation feedback (e-mail) to go to another user, | want your new user validation feedback (e-mail) to go to another user, |
| enter that user's number here. | enter that user's number here. |
| - Shutdown the BBS | - Shutdown the BBS |
| - Fix your system date/time | - Fix your system date/time |
| - Run ''exec/[[module:binkit]]'' in your Synchronet ''[[dir:ctrl]]'' directory, change the "Date Stamp" to yesterday's date | - Run ''exec/[[util:dstsedit]]'' in your Synchronet ''[[dir:ctrl]]'' directory, change the "Date Stamp" to yesterday's date |
| - Restart the BBS | - Restart the BBS |
| |
| If the source (old) computer was running Windows and you wish to preserve any changes you made to the [[:monitor:sbbsctrl|Synchronet Control Panel]] settings (stored in the Windows registry), you can export those settings to a ''sbbsctrl.ini'' file (using the File->Export Settings menu option) and then import them into the Synchronet Control Panel running on the new computer (using the File->Import Settings menu option). These settings include some changes made via the File->Properties menu. Settings made in most other menus in the Synchronet Control Panel are stored in your ''[[dir:ctrl]]/[[:config:sbbs.ini]]'' file. | If the source (old) computer was running Windows and you wish to preserve any changes you made to the [[:monitor:sbbsctrl|Synchronet Control Panel]] settings (stored in the Windows registry), you can export those settings to a ''sbbsctrl.ini'' file (using the File->Export Settings menu option) and then import them into the Synchronet Control Panel running on the new computer (using the File->Import Settings menu option). These settings include some changes made via the File->Properties menu. Settings made in most other menus in the Synchronet Control Panel are stored in your ''[[dir:ctrl]]/[[:config:sbbs.ini]]'' file. |
| |
| Configuration changes made via the ''[[module:binkit]]'' utility are stored in the ''*.cnf'' files in your ''[[dir:ctrl]]'' directory. | Configuration changes made via the ''[[:util:SCFG]]'' utility are stored in the ''*.cnf'' files in your ''[[dir:ctrl]]'' directory. |
| |
| If you wish to **only** migrate configuration and data files (e.g. over an new installation of Synchronet), copy (recursively) the following Synchronet sub-directories to the new computer: | If you wish to **only** migrate configuration and data files (e.g. over an new installation of Synchronet), copy (recursively) the following Synchronet sub-directories to the new computer: |
| |
| :?: **Question:**\\ | :?: **Question:**\\ |
| Why are there more messages in my message base than the configured **maximum number of messages** for that sub-board in [[module:binkit]]? | Why are there more messages in my message base than the configured **maximum number of messages** for that sub-board in [[util:SCFG]]? |
| |
| :!: **Answer:**\\ | :!: **Answer:**\\ |
| The maximum number of messages configured via SCFG->Message Areas ... Sub-boards (and visible when using the ''[[module:binkit]] s'' command as the ''max_msgs'' value) is enforced when the message maintenance (e.g. ''smbutil m'' command) is executed. | The maximum number of messages configured via SCFG->Message Areas ... Sub-boards (and visible when using the ''[[util:smbutil]] s'' command as the ''max_msgs'' value) is enforced when the message maintenance (e.g. ''smbutil m'' command) is executed. |
| |
| By default, Synchronet comes with a pre-configured //Timed Event// called ''MSGMAINT'', set to run weekly, which will perform normal message base maintenance on all of the message bases in your ''[[dir:data]]'' directory, including the deleting of old messages, if necessary, to meet the configured "Maximum Messages" value. Timed events may also be forced by the sysop to run immediately at any time, if desired. | By default, Synchronet comes with a pre-configured //Timed Event// called ''MSGMAINT'', set to run weekly, which will perform normal message base maintenance on all of the message bases in your ''[[dir:data]]'' directory, including the deleting of old messages, if necessary, to meet the configured "Maximum Messages" value. Timed events may also be forced by the sysop to run immediately at any time, if desired. |
| - It's only a "should" clause, which in spec-lawyer-speak, means: "you don't //[[http://ftsc.org/docs/fta-1006.002|have]]// to" (in contrast to "shall" or "must"). | - It's only a "should" clause, which in spec-lawyer-speak, means: "you don't //[[http://ftsc.org/docs/fta-1006.002|have]]// to" (in contrast to "shall" or "must"). |
| |
| So the ''origaddr'' is where Synchronet and its utilities (e.g. [[module:binkit]]) adds unique data to insure that all messages generated by a correctly-configured Synchronet system have //unique// FTN message-IDs... forever. The data we place in the ''origaddr'' is currently thus: | So the ''origaddr'' is where Synchronet and its utilities (e.g. [[util:SBBSecho]]) adds unique data to insure that all messages generated by a correctly-configured Synchronet system have //unique// FTN message-IDs... forever. The data we place in the ''origaddr'' is currently thus: |
| <msgnum>.<subcode>@<ftn_addr> | <msgnum>.<subcode>@<ftn_addr> |
| |
| ===== Old Baja ===== | ===== Old Baja ===== |
| :?: **Question:**\\ | :?: **Question:**\\ |
| Why do I get the following error when compiling an old [[module:binkit]] source (''*.src'') file: ''!SYNTAX ERROR (expecting integer constant)''? | Why do I get the following error when compiling an old [[util:Baja]] source (''*.src'') file: ''!SYNTAX ERROR (expecting integer constant)''? |
| |
| :!: **Answer:**\\ | :!: **Answer:**\\ |
