https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7296

OK, for the 2nd part of the problem, where `.?lo` is in the locks array, it looks like the regex in `lock_file(file)`, is being passed a `.?lo` file, and should return a `.bsy` file - but its not working:

```
log(LOG_INFO,"START lock_flow: "+file)
log(LOG_INFO,JSON.stringify(file.replace(/\.[^\.]*?$/, '.bsy')));
```

Returns:

```
│Jun 03 13:31:36 ⋮ local1.info synchronet: evnt BINKOUT START lock_flow: /opt/sbbs/fido/outbound.00a/00010001.flo │
│Jun 03 13:31:36 ⋮ local1.info synchronet: evnt BINKOUT "/opt/sbbs/fido/outbound.00a/00010001.flo" ┤
```

However later, an actual call doesnt have a suffix:

```
│Jun 03 13:31:45 ⋮ local1.info synchronet: evnt BINKOUT START lock_flow: /opt/sbbs/fido/outbound.00a/00010001. │
│Jun 03 13:31:45 ⋮ local1.info synchronet: evnt BINKOUT "/opt/sbbs/fido/outbound.00a/00010001.bsy" │
```

Retsulting in the correct lock file being returned.

The regex should probably be replaced with:

`file.replace(/\.[^\.]*$/, '.bsy')`

(Note the removal of the question mark.)
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7297

And FWIW, I changed the regex, and the 1st issue disappeared? Was the flow file locked by the original call to lock_file?
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7298

Maybe log the _name_ of the file that was successfully opened (in your "Hello debugging mode" log message) and then we can tell if the flo file is being opened more than once by BinkIt.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7299

I dont think that is where the problem is - and yes, the call to `new File(file)` was only attempting to open the file once to the best of my knowledge. (I added heaps of logging to find that regex.)

I think the problem started in `add_outbound_files`, specifically in the loop `addrs.forEach` at the call `lock_flow`.

lock_flow received a `.?lo` file as an argument, and (based on what I think the regex was trying to do), should have created a `.bsy` file as a lock file. Except it was locking the `.?lo` file.

Then the call to flo.open('r') was failing, because the file was locked.

Then later the `bsy` file was deleted as part of unlocking (excepted it was the `.?lo` file).

Make sense?
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7300

What I dont understand, is why the event server couldnt open the file, but `jsexec` could.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7302

Wanting Deuce's input on this one .
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7311

OK, thought I'd share my test:

```js
var files = [
'/opt/sbbs/fido/outbound.00a/00010001.flo', '/opt/sbbs/fido/outbound.00a/00010001.bsy', '/opt/sbbs/fido/outbound.00a/00010001.',
];

files.forEach(function(file) {
var oldregex = file;
var newregex = file;

writeln("FILE:"+file);
writeln("OLDREGEX:"+oldregex.replace(/\.[^\.]*?$/, '.bsy'));
writeln("NEWREGEX:"+newregex.replace(/\.[^\.]*$/, '.bsy'));
writeln("-");
});
```

Result:
```
FILE:/opt/sbbs/fido/outbound.00a/00010001.flo OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.flo NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
-
FILE:/opt/sbbs/fido/outbound.00a/00010001.bsy OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
-
FILE:/opt/sbbs/fido/outbound.00a/00010001. OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
```

Seems that regex ungreedy is not working (at least for me on aarch64).
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7314

Are you building Spidermonkey from the source in the repo, or are you using some 3rd-party build? It looks like regexps are broken on your system.

There should be no difference in behaviour between those two regexps, but there's a _lot_ of regexps that will be subtly broken if using a ? makes them not match at all.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7315

For what it's worth, here's that same test executed with a supported version of SpiderMonkey:

```
$ jsexec regextest

JSexec v3.21a-Linux master/dd0e146a0 Debug - Execute Synchronet JavaScript Module
Compiled May 28 2025 21:56 with GCC 12.2.0

Loading configuration files from /sbbs/ctrl
JavaScript-C 1.8.5 2011-03-31
JavaScript: Creating runtime: 167772160 bytes

Reading script from /sbbs/exec/regextest.js
/sbbs/exec/regextest.js compiled in 0.00 seconds FILE:/opt/sbbs/fido/outbound.00a/00010001.flo OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
-
FILE:/opt/sbbs/fido/outbound.00a/00010001.bsy OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
-
FILE:/opt/sbbs/fido/outbound.00a/00010001. OLDREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy NEWREGEX:/opt/sbbs/fido/outbound.00a/00010001.bsy
-
/sbbs/exec/regextest.js executed in 0.00 seconds
```
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7316

I'm building everything (same as I have always done).

The build script is here: https://gitea.dege.au/bbs/sbbs/src/branch/master/docker/Dockerfile#L25, and the build output for this run is here: https://gitea.dege.au/bbs/sbbs/actions/runs/8
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7318

Looks like Darwin-x86 passes that test though, so the issue does seem to be tracking ARM/aarch64 builds.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7319

To be clear, the ? can be removed from that regex with no problem.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/936
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/936#note_7352

Since we have a work-around with the changed regex, I'll close this issue.
--- SBBSecho 3.27-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)