• Re: File Request question

    From Gamgee@1:103/705 to Digital Man on Mon Dec 22 10:40:41 2025
    Digital Man wrote to RickV <=-

    Re: File Request question
    By: RickV to Mindsurfer on Sun Dec 21 2025 06:34 am

    Thank you. I was really looking to find out how you send a netmail for a file request. It's been a long time since I've done that.

    To send a FidoNet file request netmail from Synchronet, the user needs
    to either be a sysop or have the 'F' exemption and then include "FR:<filename>" as the subject of the netmail message they're sending.

    Thank you also for the new writeup posted on the Wiki for this. I
    tested that this morning, to my system from a "test point" that I have.
    It worked properly, but it did result in the file being sent twice,
    because there ended up being (2) File Requests (.req) sent, for reasons unknown. The requesting system is also running SBBS, if that matters.
    The second file received just over-wrote the first one, in the
    "inbound" directory, so no real harm done, but seems off a little.
    Here's a log snippet of the transaction, from the system that received
    the two requests:

    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP JSBinkP/4 inbound connection from 198.74.54.171:55602
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Will encrypt session.
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Peer version: BinkIT/2.42,JSBinkP/4,sbbs3.21a/Linux
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Remote addresses: 1:135/115.7@fidonet
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Inbound session for: 1:135/115.7@fidonet
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP CRAM-MD5 password match for 1:135/115.7@fidonet
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Receiving file: /sbbs/temp/00870073.req (0.0KB)
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Received file: /sbbs/temp/00870073.req (0.0KB)
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Deleted file: /sbbs/temp/00870073.req
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Sending file: /files/main/uploads/pal2512.zip (1431.5KB)
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Receiving file: /sbbs/temp/neqzr8wk.req (0.0KB)
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Received file: /sbbs/temp/neqzr8wk.req (0.0KB)
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP Deleted file: /sbbs/temp/neqzr8wk.req
    Dec 22 09:16:25 palantir synchronet: srvc 0013 BINKP We got an M_EOB, but there are still 1 files pending M_GOT
    Dec 22 09:16:27 palantir synchronet: srvc 0013 BINKP Sent file: /files/main/uploads/pal2512.zip (1431.5KB)
    Dec 22 09:16:27 palantir synchronet: srvc 0013 BINKP Sending file: /files/main/uploads/pal2512.zip (1431.5KB)
    Dec 22 09:16:30 palantir synchronet: srvc 0013 BINKP Sent file: /files/main/uploads/pal2512.zip (1431.5KB)
    Dec 22 09:16:32 palantir synchronet: srvc 0013 BINKP [198.74.54.171] JavaScript service thread terminated (0 clients remain, 0 total, 616 served)


    Maybe there's something there that would indicate what caused the
    duplicate request messages, but not likely to my eye. The first .req is
    the hex conversion of the receiving systems FTN address (1:135/115), and
    the second .req appears to be a random-generated name from the
    requesting system.

    Thanks for any info you may be able to provide on this!



    ... I was on a roll till I slipped on the butter.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Gamgee on Mon Dec 22 14:07:32 2025
    Re: Re: File Request question
    By: Gamgee to Digital Man on Mon Dec 22 2025 10:40 am

    Thank you also for the new writeup posted on the Wiki for this. I
    tested that this morning, to my system from a "test point" that I have.
    It worked properly, but it did result in the file being sent twice,
    because there ended up being (2) File Requests (.req) sent, for reasons unknown. The requesting system is also running SBBS, if that matters.
    The second file received just over-wrote the first one, in the
    "inbound" directory, so no real harm done, but seems off a little.
    Here's a log snippet of the transaction, from the system that received
    the two requests:

    The sbbsecho.log messages concerning the file request would likely be more helpful.
    --
    digital man (rob)

    Steven Wright quote #15:
    Depression is merely anger without enthusiasm.
    Norco, CA WX: 71.4øF, 59.0% humidity, 4 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.33-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deuce@1:103/705 to Tanausu M. on Mon Dec 29 04:20:49 2025
    Re: Re: File Request question
    By: Tanausu M. to Deuce on Sat Dec 27 2025 06:37 pm

    I send a netmail with FR:AP251227.ZIP, but when I check the log, it appears without the extension and I receive an error message.

    Here's the log:

    2025-12-27 17:30:02 Created NetMail (1.msg) from Tanausu Martin (21:3/219) to Andrew Leary (21:4/105), attr: 0981 (PRIVATE, KILLSENT, LOCAL, FREQ), subject: AP251227.

    This is more a Digital Man issue, but I do note that the prefix ("FR:") is the same length as the part truncated from the end ("ZIP").

    Not sure if that's related or not.
    ---
    þ Synchronet þ The future of BBSing
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tanausu M.@1:103/705 to Deuce on Mon Dec 29 10:56:58 2025
    I send a netmail with FR:AP251227.ZIP, but when I check the log, it appears without the extension and I receive an error message.

    Here's the log:

    2025-12-27 17:30:02 Created NetMail (1.msg) from Tanausu Martin (21:3/219) to Andrew Leary (21:4/105), attr: 0981 (PRIVATE, KILLSENT, LOCAL, FREQ), subject: AP251227.

    This is more a Digital Man issue, but I do note that the prefix ("FR:")
    is the same length as the part truncated from the end ("ZIP").

    Not sure if that's related or not.

    Yes, it seems so. With the latest patch you released, it no longer sends duplicates.

    --- MultiMail/FreeBSD v0.52
    þ Synchronet þ Citrick BBS
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Deuce on Mon Dec 29 03:55:18 2025
    Re: Re: File Request question
    By: Deuce to Tanausu M. on Mon Dec 29 2025 04:20 am

    Re: Re: File Request question
    By: Tanausu M. to Deuce on Sat Dec 27 2025 06:37 pm

    I send a netmail with FR:AP251227.ZIP, but when I check the log, it appears without the extension and I receive an error message.

    Here's the log:

    2025-12-27 17:30:02 Created NetMail (1.msg) from Tanausu Martin (21:3/219) to Andrew Leary (21:4/105), attr: 0981 (PRIVATE, KILLSENT, LOCAL, FREQ), subject: AP251227.

    This is more a Digital Man issue, but I do note that the prefix ("FR:") is the same length as the part truncated from the end ("ZIP").

    Not sure if that's related or not.

    I wasn't able to reproduce this (see the extension is included in the filename from the file request subject line):

    12/29/25 03:53:36 Created NetMail (2.msg) from Rob Swindell (1:103/705) to wx6yyz (1:103/13), attr: 0983 (PRIVATE, CRASH, KILLSENT, LOCAL, FREQ), subject: FILENAME.EXT
    12/29/25 03:53:36 BSO file request from Rob Swindell (1:103/705) to wx6yyz (1:103/13): FILENAME.EXT
    --
    digital man (rob)

    Rush quote #21:
    You can surrender without a prayer, but never really pray without surrender Norco, CA WX: 57.8øF, 29.0% humidity, 3 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.34-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deuce@1:103/705 to Digital Man on Mon Dec 29 16:57:18 2025
    Re: Re: File Request question
    By: Digital Man to Deuce on Mon Dec 29 2025 03:55 am

    I wasn't able to reproduce this (see the extension is included in the filename from the file request subject line):

    I assume it's not doing some archive weirdness...
    ---
    þ Synchronet þ The future of BBSing
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tanausu M.@1:103/705 to Digital Man on Mon Dec 29 18:53:08 2025
    Re: Re: File Request question
    By: Digital Man to Deuce on Mon Dec 29 2025 03:55:18

    I wasn't able to reproduce this (see the extension is included in the filename from the file request subject line):

    12/29/25 03:53:36 Created NetMail (2.msg) from Rob Swindell (1:103/705) to wx6yyz (1:103/13), attr: 0983 (PRIVATE, CRASH, KILLSENT, LOCAL, FREQ), subject: FILENAME.EXT
    12/29/25 03:53:36 BSO file request from Rob Swindell (1:103/705) to wx6yyz (1:103/13): FILENAME.EXT
    --
    digital man (rob)

    Hello. I've also provided little to no information. I'm currently using what I believe is one of the latest versions of dailybuild_linux_x64, but with FreeBSD 15. I don't know if the master branch would change anything regarding that minor bug.
    Currently, I can't switch the server to another Linux system. It's something beyond my control.

    What I've done is create a script, and it seems to avoid that bug. Does anyone know where the bug is? I'll have to compile the master branch to see if it disappears and saves me all this trouble.

    Sorry for filling up the message with all of the following.

    events.log

    2025-12-29 18:24:27 BINKOUT Call attempt to 1:229/700@fidonet, file: /sbbs/fido/outbound.001/00e502bc.clo
    2025-12-29 18:24:27 BINKOUT JSBinkP/4 call to 1:229/700@fidonet initiated 2025-12-29 18:24:29 BINKOUT Connecting to 1:229/700@fidonet on mysticrealms.ddns.net:24554
    2025-12-29 18:24:30 BINKOUT Authentication successful: not secure
    2025-12-29 18:24:30 BINKOUT Sending file: /sbbs/fido/outbound.001/00e502bc.req (0.0KB)
    2025-12-29 18:24:30 BINKOUT File sent: /sbbs/fido/outbound.001/00e502bc.req (0.0KB)
    2025-12-29 18:24:30 BINKOUT We received an M_EOB, but there is still an M_GOT file pending.
    2025-12-29 18:24:30 BINKOUT File deleted: /sbbs/fido/outbound.001/00e502bc.clo 2025-12-29 18:24:30 BINKOUT File deleted: /sbbs/fido/outbound.001/00e502bc.req 2025-12-29 18:24:31 BINKOUT Timed event: '?binkit' returned 0



    sbbsecho.log

    2025-12-29 18:24:22 NetMail (1.msg) created from Tanausu Martin (2:341/207) to Jeff Earle (1:229/700), attr: 0983 (PRIVATE, CRASH, KILLSENT, LOCAL, FREQ), subject: FR:AP251228.ZIP
    2025-12-29 18:24:22 OST file request from Tanausu Martin (2:341/207) to Jeff Earle (1:229/700): FR:AP251228.ZIP
    2025-12-29 18:24:22 BSO/FLO file shrunk for 1:229/700: ../fido/outbound.001/00e502bc.clo
    2025-12-29 18:24:22 SBBSecho (PID 95438) ending with error level 0, NetMail (0 imported, 1 exported, 0 packaged)

    Debug:
    === Only variables/properties ===
    from = Tanausu Martin
    from_net_type = 2
    from_net_addr = 2:341/207
    a = Jeff Earle
    to_net_type = 2
    to_net_addr = 1:229/700
    subject = FR:AP251228.ZIP
    attr = 1
    auxattr = 8193
    netattr = 73
    -----Header Properties-----
    from (string) = Tanausu Martin
    from_net_type (number) = 2
    from_net_addr (string) = 2:341/207
    a (string) = Jeff Earle
    to_net_type(number) = 2
    to_net_addr (string) = 1:229/700
    subject(string) = FR:AP251228.ZIP
    attribute(number) = 1
    auxiliary_attribute(number) = 8193
    netattr (number) = 73
    -----end of header-----

    var new_hdr =
    {
    from: name_of_from,
    from_network_type: hdr.to_network_type,
    from_network_address: aka,
    to: subject_name,
    from_network_type: hdr.to_network_type,
    from_network_address: subject.address,
    subject: parts.subject,
    attribute: hdr.attribute,
    attribute: hdr.attribute,
    attribute: hdr.attribute,
    netattr: hdr.netattr
    };

    // Check if the message is a file request
    // If so, set the flag and let sbbs do the rest
    if (new_hdr.subject != null && new_hdr.subject.substring(0, 3) === "FR:")
    {
    new_hdr.netattr |= NETMSG_LOCAL | NETMSG_KILLSENT | NETMSG_CRASH;
    new_hdr.auxattr |= MSG_FILEREQUEST;
    }

    getproperties(new_hdr)
    dump_header_props(new_hdr);

    if(!msgbase.save_msg(new_hdr, parts.body))
    {
    print("Error sending message\n");
    continue;
    }

    //Mark the original as deleted
    hdr.attr |= MSG_DELETE;

    if(!msgbase.put_msg_header(true, msg_nodelete[a], hdr))
    print("Error updating header for offset " + msg_nodelete[a]);

    ---
    þ Synchronet þ Citrick BBS
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Tanausu M. on Mon Dec 29 13:33:54 2025
    Re: Re: File Request question
    By: Tanausu M. to Digital Man on Mon Dec 29 2025 06:53 pm

    What I've done is create a script, and it seems to avoid that bug. Does anyone know where the bug is? I'll have to compile the master branch to see if it disappears and saves me all this trouble.

    Sorry for filling up the message with all of the following.

    sbbsecho.log

    2025-12-29 18:24:22 NetMail (1.msg) created from Tanausu Martin (2:341/207) to Jeff Earle (1:229/700), attr: 0983 (PRIVATE, CRASH, KILLSENT, LOCAL, FREQ), subject: FR:AP251228.ZIP

    The "FR:" isn't supposed to actually be part of the subject stored in the message header. If you include the "FR:" prefix in a netmail subject that you enter from within Synchronet (the terminal server), it'll strip the "FR:" prefix and add the FREQ attribute. This message you're showing has both the FREQ attribute *and* the "FR:" prefix in the subject. That's not correct.
    --
    digital man (rob)

    Rush quote #25:
    Throw off those chains of reason and your prison disappears
    Norco, CA WX: 67.0øF, 21.0% humidity, 15 mph NE wind, 0.00 inches rain/24hrs --- SBBSecho 3.34-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)