Hey Rob,

I was playing with FTN messages with attachments today and it didnt work completely...

I'm sending from:
SBBS/BINKIT 516:1/2 -> BINKD/HPT 516:516/0 -> SBBS/BINKIT 516:1/1

The message left 1/2 fine, 516/0 processed it fine and sent it to 1/1 (including the attachment).

However, when 1/1 went to import it, it was looking for the attachment in nonsecure, when in fact it was a secure transfer:

2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported

(The attachment "test" is in /opt/sbbs/fido/inbound.)

From 1/1's POV, 516/0 is defined in sbbsecho.ini and thus should be a secure session - so it shouldnt be looking for attachments from that node in unsecure.

Right?

...ëîåï

... I almost had a psychic girlfriend but she left me before we met.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sat Jul 18 2020 05:42 pm

Hey Rob,

I was playing with FTN messages with attachments today and it didnt work completely...

I'm sending from:
SBBS/BINKIT 516:1/2 -> BINKD/HPT 516:516/0 -> SBBS/BINKIT 516:1/1

The message left 1/2 fine, 516/0 processed it fine and sent it to 1/1 (including the attachment).

However, when 1/1 went to import it, it was looking for the attachment in nonsecure, when in fact it was a secure transfer:

2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported

(The attachment "test" is in /opt/sbbs/fido/inbound.)

From 1/1's POV, 516/0 is defined in sbbsecho.ini and thus should be a secure session - so it shouldnt be looking for attachments from that node in unsecure.

Right?

Right. I'll experiment and see if I can reproduce (and then fix) the issue.

digital man

Synchronet/BBS Terminology Definition #16:
CVS = Concurrent Versioning System
Norco, CA WX: 85.0øF, 45.0% humidity, 7 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 12:24 pm

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sat Jul 18 2020 05:42 pm

Hey Rob,

I was playing with FTN messages with attachments today and it didnt work completely...

I'm sending from:
SBBS/BINKIT 516:1/2 -> BINKD/HPT 516:516/0 -> SBBS/BINKIT 516:1/1

The message left 1/2 fine, 516/0 processed it fine and sent it to 1/1 (including the attachment).

However, when 1/1 went to import it, it was looking for the attachment in nonsecure, when in fact it was a secure transfer:

2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported

(The attachment "test" is in /opt/sbbs/fido/inbound.)

From 1/1's POV, 516/0 is defined in sbbsecho.ini and thus should be a secure session - so it shouldnt be looking for attachments from that node in unsecure.

Right?

Right. I'll experiment and see if I can reproduce (and then fix) the issue.

And I tested it here and it worked fine:
7/18 12:26:15p 2512 BINKP BinkIT/2.39 invoked with options:
7/18 12:26:15p 2512 BINKP JSBinkP/1.123 inbound connection from 45.32.85.113:24635
7/18 12:26:16p 2512 BINKP Peer version: BinkIT/2.27,JSBinkP/1.123,sbbs3.18a/FreeBSD binkp/1.1
7/18 12:26:16p 2512 BINKP Remote addresses: 1:103/13@fidonet
7/18 12:26:16p 2512 BINKP Inbound session for: 1:103/13@fidonet
7/18 12:26:16p 2512 BINKP CRAM-MD5 password match for 1:103/13@fidonet
7/18 12:26:16p 2512 BINKP Receiving file: e:\sbbstemp\attfile.txt (0.0KB)
7/18 12:26:16p 2512 BINKP Received file: e:\sbbstemp\attfile.txt (0.0KB)
7/18 12:26:16p 2512 BINKP Moving 'e:\sbbstemp\attfile.txt' to '../fido/inbound\attfile.txt'.
7/18 12:26:16p 2512 BINKP Receiving file: e:\sbbstemp\4gpk8o6r.pkt (0.4KB)
7/18 12:26:16p 2512 BINKP Received file: e:\sbbstemp\4gpk8o6r.pkt (0.4KB)
7/18 12:26:16p 2512 BINKP Moving 'e:\sbbstemp\4gpk8o6r.pkt' to '../fido/inbound\4gpk8o6r.pkt'.
7/18 12:26:16p 2512 BINKP service thread terminated (0 clients remain, 0 total, 5 served)

07/18/20 12:26:15 Importing /share/sbbs/fido/inbound/4gpk8o6r.pkt (Type 2+, 0.4KB) from 1:103/13 to 1:103/705
07/18/20 12:26:15 Robert R Swindell (1:103/13) To: sysop (1:103/705) Imported

And the attfile.txt was successfully moved to my data/user/0001.in directory and attached to the email.

What version of SBBSecho are you using?

I'm going to add some more log output to indicate exactly what's happening with more detail and hopefully get to the bottom of the issue you're having. Assuming you're willing to do some more testing?

digital man

Sling Blade quote #18:
Karl Childers: Some folks call it Hell, I call it Hades.
Norco, CA WX: 86.8øF, 41.0% humidity, 11 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 12:24 pm

2020-07-18 17:25:29 MV ERROR: Source doesn't exist
'/opt/sbbs/fido/nonsecure/test

Right. I'll experiment and see if I can reproduce (and then fix) the issue.

I wanted to suggest as well, that when you send attachments, that the attachment is renamed to something that is likely to be more unique, while it is transferring, but is downloadable with its original name.

I know this might be a long shot? IE: Other software may not know how to rename it back?

The scenario I was thinking might be a problem is if 2 people send 2 different attachments with the same name, that are in the fido/inbound at the same time. It seems that the second file coming in (with the same name) clobers the first?

(I had exactly that while testing this..)

...ëîåï

... Friends may come and friends may go, but enemies accumulate.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 04:36 pm

And I tested it here and it worked fine:
And the attfile.txt was successfully moved to my data/user/0001.in directory and attached to the email.

Dont you hate it when that happens? :)

What version of SBBSecho are you using?

Fairly recent build: Built 10 days ago. (Running on a Pi)
SBBSecho v3.11-Linux (rev 3.173) - Synchronet FidoNet EchoMail Tosser

having. Assuming you're willing to do some more testing?

Yes, happy to.

And in case you need it - here is binkp:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)

...ëîåï

... Everybody has a right to pronounce foreign names as he chooses.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sun Jul 19 2020 09:31 am

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 12:24 pm

2020-07-18 17:25:29 MV ERROR: Source doesn't exist
'/opt/sbbs/fido/nonsecure/test

Right. I'll experiment and see if I can reproduce (and then fix) the issue.

I wanted to suggest as well, that when you send attachments, that the attachment is renamed to something that is likely to be more unique, while it is transferring, but is downloadable with its original name.

I know this might be a long shot? IE: Other software may not know how to rename it back?

The scenario I was thinking might be a problem is if 2 people send 2 different attachments with the same name, that are in the fido/inbound at the same time. It seems that the second file coming in (with the same name) clobers the first?

(I had exactly that while testing this..)

Yeah, file attachments in FidoNet were not very well designed.

digital man

This Is Spinal Tap quote #16:
David St. Hubbins: I believe virtually everything I read...
Norco, CA WX: 74.6øF, 61.0% humidity, 7 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sun Jul 19 2020 11:25 am

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 04:36 pm

And I tested it here and it worked fine:
And the attfile.txt was successfully moved to my data/user/0001.in directory and attached to the email.

Dont you hate it when that happens? :)

What version of SBBSecho are you using?

Fairly recent build: Built 10 days ago. (Running on a Pi)
SBBSecho v3.11-Linux (rev 3.173) - Synchronet FidoNet EchoMail Tosser

having. Assuming you're willing to do some more testing?

Yes, happy to.

And in case you need it - here is binkp:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)

There should've been more log lines with regards to "test" (Received, Moving).

digital man

Synchronet/BBS Terminology Definition #43:
IP = Internet Protocol
Norco, CA WX: 74.6øF, 61.0% humidity, 7 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:28 pm

There should've been more log lines with regards to "test" (Received, Moving).

Yes, there was, strangely this session took all up 7 minutes to "complete":

(It took 7 mins to complete this binkit session - 17:22:08 to 17:29:24, and the 2 systems are on the same host... <wondering if that is related>?)

Here is the complete log:
$ sudo grep 0020 /var/log/messages|grep "Jul 18"|grep 17:2
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP connection accepted from: 172.17.0.1 port 54306
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/test' to '../fido/inbound/test'.
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)

...ëîåï

... Children are a comfort in old age, and they will even help you reach it.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sun Jul 19 2020 01:46 pm

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:28 pm

There should've been more log lines with regards to "test" (Received, Moving).

Yes, there was, strangely this session took all up 7 minutes to "complete":

(It took 7 mins to complete this binkit session - 17:22:08 to 17:29:24, and the 2 systems are on the same host... <wondering if that is related>?)

Here is the complete log:
$ sudo grep 0020 /var/log/messages|grep "Jul 18"|grep 17:2
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP connection accepted from: 172.17.0.1 port 54306
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP BinkIT/2.39 invoked with options:
Jul 18 17:22:08 p-1-1 synchronet: srvc 0020 BINKP JSBinkP/1.123 inbound connection from 172.17.0.1:54306
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Peer version: binkd/1.1a-109/Linux binkp/1.1
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Will encrypt session.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Remote addresses: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Inbound session for: 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP CRAM-MD5 password match for 516:516/0@videotex
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/9e6eb2ff.pkt (0.8KB)
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/9e6eb2ff.pkt' to '../fido/inbound/9e6eb2ff.pkt'.
Jul 18 17:22:09 p-1-1 synchronet: srvc 0020 BINKP Receiving file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Received file: /opt/sbbs/temp/test (2960.3KB)
Jul 18 17:25:37 p-1-1 synchronet: srvc 0020 BINKP Moving '/opt/sbbs/temp/test' to '../fido/inbound/test'.
Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)

If you send a smaller file, do you have the same problem?

Is it possible that SBBSecho was run while binkit was still receiving the file attachment? Normally BinkIT shouldn't signal the semaphore to trigger SBBSecho import (e.g. fidoin.now) until the BINKP session is done. And you should see a debug-level log message like this one:
Jul 18 20:21:14 cvs sbbs: srvc 0051 BINKP Touching semaphore file: /sbbs/data/fidoin.now

If you have SBBSecho running frequently and independantly of BinkIT, that could cause a race condition where the netmail message is processed while the attached file hasn't yet been full received.

digital man

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 73.0øF, 65.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:52 pm

Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated
(0 clients remain, 0 total, 409 served)

If you have SBBSecho running frequently and independantly of BinkIT, that could cause a race condition where the netmail message is processed while the attached file hasn't yet been full received.

In this case, no, sbbsecho started 4 seconds after:

Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)
Jul 18 17:29:25 p-1-1 synchronet: evnt DAILY Semaphore signaled for Timed Event: FIDOIN
Jul 18 17:29:25 p-1-1 synchronet: evnt FIDOIN Running native timed event: FIDOIN
Jul 18 17:29:31 p-1-1 synchronet: evnt FIDOIN Timed event: FIDOIN returned 0

sbbsecho.log

2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported

If you send a smaller file, do you have the same problem?

Of it looking in insecure for the attachment? I'll try...

...ëîåï

... Old age is life's parody.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: alterego to Digital Man on Sun Jul 19 2020 03:17 pm

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 08:52 pm

Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated
(0 clients remain, 0 total, 409 served)

If you have SBBSecho running frequently and independantly of BinkIT, that could cause a race condition where the netmail message is processed while the attached file hasn't yet been full received.

In this case, no, sbbsecho started 4 seconds after:

Jul 18 17:29:24 p-1-1 synchronet: srvc 0020 BINKP service thread terminated (0 clients remain, 0 total, 409 served)
Jul 18 17:29:25 p-1-1 synchronet: evnt DAILY Semaphore signaled for Timed Event: FIDOIN
Jul 18 17:29:25 p-1-1 synchronet: evnt FIDOIN Running native timed event: FIDOIN
Jul 18 17:29:31 p-1-1 synchronet: evnt FIDOIN Timed event: FIDOIN returned 0

sbbsecho.log

2020-07-18 17:25:29 Importing /opt/sbbs/fido/inbound/9e6eb2ff.pkt (Type 2e, 0.8KB) from 516:516/0 to 516:1/1
2020-07-18 17:25:29 MV ERROR: Source doesn't exist '/opt/sbbs/fido/nonsecure/test
2020-07-18 17:25:29 Deon George (516:1/2) To: alterego (516:1/1) Imported

If you send a smaller file, do you have the same problem?

Of it looking in insecure for the attachment? I'll try...

Well it first looks in the same directory as the packet (in this case, /opt/sbbs/fido/inbound), but that's not logged and *then* it looks in the other directory (e.g. your non-secure inbound). This is more clear with the newest commit which added a few more log messages.

It sounds like the file wasn't in the inbound at the time that SBBSecho looked.

digital man

Synchronet/BBS Terminology Definition #57:
Phreak = Telephone system hack[er]
Norco, CA WX: 67.3øF, 75.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 10:55 pm

If you send a smaller file, do you have the same problem?

So I did send a smaller file and it worked (I havent recompiled yet). So I'll try again with something larger and see if it happens again.

Well it first looks in the same directory as the packet (in this case, /opt/sbbs/fido/inbound), but that's not logged and *then* it looks in the other directory (e.g. your non-secure inbound). This is more clear with the newest commit which added a few more log messages.

It sounds like the file wasn't in the inbound at the time that SBBSecho looked.

Hmm... OK strange indeed - especially since the logging shows sbbsecho was executed after the binkp session.

I thought it may be related to me sending 2 netmails (with different bodies), but the same file attachment (and the same name). Since this actually results in only 1 (attachment) in the inbound (since it was routed), I double checked to see if 1 of the messages had the attachment, but sadly both didnt have it. <confused>

I'll recompile and see if I can reproduce it.

...ëîåï

... The cure for admiring the house of lords is to go and look at it.

---
þ Synchronet þ Alterant | an SBBS in Docker on Pi!

Re: Routed FTN messages with attachments
By: Digital Man to alterego on Sat Jul 18 2020 20:26:50

The scenario I was thinking might be a problem is if 2 people send 2
different attachments with the same name, that are in the fido/inbound
at the same time. It seems that the second file coming in (with the
same name) clobers the first?

(I had exactly that while testing this..)

Yeah, file attachments in FidoNet were not very well designed.

traditional (dynamic) FTN mailers rename the 2nd and subsequent files of the same name... generally by incrementing a digit on the extension... smart (dynamic) mailers would also change the message to point to the new file
name... this as long as they were the ones to handle unpacking the netmail... some FTN tossers also have some of this ability but yeah, it is a bit flawed...


)\/(ark

---
þ Synchronet þ The SouthEast Star Mail HUB - SESTAR