=====================================================================
WARNING FOR C-NET/5 SYSOPS RUNNING UNDER AMIBERRY
Two emulator behaviours that silently break a working board =====================================================================

Neither of these is a C-Net bug. Both are Amiberry doing something
real Amiga hardware never did, and both fail SILENTLY - no Guru, no
error, nothing in any log. Swapping C-Net versions will not change
either one, which is exactly what makes them so hard to find.

Seen on Amiberry 8.3.0 with C-Net 5.37b, but the mechanisms are not
version specific.


---------------------------------------------------------------------
1. LOCAL MAIL SILENTLY DISAPPEARS ---------------------------------------------------------------------

SYMPTOMS

* MS <user> completes normally and the mail never arrives.
* [F]eedback vanishes the same way.
* New user applications never reach you, and the NEW USER instead
gets a bounce: "User does not exist at this location."
* No error is shown to the caller, nothing is logged, and no
bounce comes back for MS or feedback - the mail is just gone.
* It creeps up on you. Mailboxes die one at a time over weeks,
so there is no single date where "everything broke".

CAUSE

C-Net sets the Amiga protection bits to -------d on every mail file
it writes. On real AmigaOS those bits are advisory and DOS opens
the file anyway.

Amiberry, on a DIRECTORY-MAPPED drive, mirrors those bits onto the
host filesystem as mode 0064 (----rw-r--). The owner loses read and
write. Amiberry RUNS as that owner, so the next delivery cannot
open the mailbox and the mail is dropped.

The result: every mailbox works for exactly ONE delivery, then
locks itself forever.

This affects directory-mapped drives only (uaehf#=dir in your
config). Hardfile images (.hdf) are not affected.

HOW TO CHECK

From the host, look at any mailbox:

ls -l Mail/users/<user>/FOLDERS/INBOX/

If _mhead4 and _mtext4 show ----rw-r-- (mode 064), that mailbox
can no longer receive mail. If you also see .uaem sidecar files
next to them, that is the mechanism.

A quick census of how widespread it is:

find Mail/users -name "_mhead4" ! -perm -u+rw | wc -l

THE FIX

1. In your Amiberry config (.uae), add:

filesys_custom_uaefsdb=false

This is the GUI option "Create .uaem metadata files" - turn it
OFF. It stops Amiberry writing the sidecars, and with them the
permission mirroring.

2. Restart Amiberry. The setting is read at startup.

3. Clean up the damage already on disk. BACK UP FIRST:

find Mail/users -name "*.uaem" -delete
find Mail/users -type f ! -perm -u+rw -print0 \
| xargs -0 chmod u+rw

Step 3 matters. Step 1 only stops NEW sidecars; the existing ones
are read back and keep the old protection bits alive.

HOW TO CONFIRM IT WORKED

Send yourself mail, then check the file again. If it is still
mode 664 afterwards, the cycle is broken. If it went back to 064,
the emulator is still mirroring and the fix did not take.

Note: a chmod on its own is worth exactly ONE delivery per
mailbox. Without the config change C-Net re-strips the bits on the
next write and you are back where you started.

TRADE-OFF

The .uaem sidecars also stored Amiga file comments and timestamps.
If something on your board depends on file comments, weigh that
first. Most boards do not.


---------------------------------------------------------------------
2. A CALLER'S PORT HANGS, THEN THE WHOLE BOARD GOES DOWN ---------------------------------------------------------------------

SYMPTOMS

* A caller hangs at a fixed point - commonly during NEW USER
signup, or when a caller pages you with CHAT.
* About two minutes later Guardian reports:

Port n Has crashed!
Where: NewUser
Port n Attempting to close crashed port

* Guardian's recovery then declares EVERY other port crashed too,
and the board is down until it is restarted.
* There is no Software Failure and no Guru. The machine is still
alive - other tasks keep running and logging.

CAUSE

STOCK bbstext ships these two lines:

line 61 {$0 oplay SysData:chat.snd}
line 162 ...Now paging the SysOp!{$0 oplay SysData:chat.snd}

{$n ...} runs a DOS command and C-Net WAITS for it to finish.
oplay opens audio.device and waits for the sample to play out.

If Amiberry has no working audio (sound_output=none, or volumes
at zero), that completion never arrives. oplay never returns, and
the caller's port waits on it forever.

The "crash" is Guardian's watchdog timing out an unresponsive
port, not an actual crash. That is why the delay is always about
two minutes - it is the watchdog interval, not your code.

HOW TO CHECK

Look for the trigger:

grep -n oplay bbstext

and check your .uae for:

sound_output=none

If you have both, you have this problem.

THE FIX - PICK ONE

a) Give Amiberry working audio. Set sound_output and the volume
settings properly and restart. You keep the audible page.

b) If you do not use the sounds, remove the trigger from bbstext
lines 61 and 162.

*** BBSTEXT IS POSITIONAL. Do NOT delete the line. ***

Every line in bbstext is referenced by number, so deleting one
renumbers everything after it and breaks unrelated things. Blank
the line in place, or replace it with real text, keeping the
total line count identical.

Line 162 also carries the visible "Now paging the SysOp!" text -
strip only the {$0 oplay ...} part and leave the message.

Line 61 is invisible to the caller in stock form, so if you blank
it, leave it EMPTY. Do not put {} there - C-Net prints {} to the
caller literally. Line 61 is shown only during new user signup,
so it is a reasonable place for something like "SysOp has been
notified." if you want it.

GENERAL WARNING

Any {$n ...} in bbstext runs a DOS command that C-Net blocks on.
Anything that can stall - audio, a network call, a missing
volume - will hang the caller's port with no diagnostic at all.
Audit your {$ } lines before blaming C-Net.


---------------------------------------------------------------------
HOW TO RECOGNISE THIS CLASS OF PROBLEM ---------------------------------------------------------------------

* No fault, no Guru, no log entry. A real C-Net bug usually says
something.
* Swapping the C-Net binary changes nothing. If several versions
behave identically, the fault is below C-Net.
* The machine stays alive while one thing is stuck, or an
operation silently does nothing at all.
* The timing tracks an emulator or host change, not anything you
did to the BBS.

Same family, both documented elsewhere: SetFileDate() can block
forever when another process holds the file, and Amiberry caches
the host file handle of anything being written, so an Amiga-side
Delete comes back "object in use".


---------------------------------------------------------------------

Both issues above were found and fixed on a live board in
September 2026. If this saves you a weekend, it was worth typing.

Corrections and additions welcome.

Spitfire - Reign of Fire BBS
www.rofbbs.com - 1:154/50

=====================================================================

+ call.rofbbs.com:6800 call@call.rofbbs.com 423-541-8271 IPv4 & IPv6
+ ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
--- C-Net/5
* Origin: Reign of Fire : ROF FTN : ArakNet 2.0 : www.rofbbs.com (1:154/50)