1. Forum
  2. FidoNet
  3. BINKD

  • skipping files (bug?)

    From Oli@2:280/464.47 to All on Saturday, January 02, 2021 11:41:08
    How does file skipping work in Binkd? I'm on a bad/slow mobile connection at the moment and only want to receive mails, no nodelist updates. So I put

    skip all !0 DAILYUTF.*

    in binkd.cfg, but the file doesn't seem to get deleted on the other side:

    - 11:28 [1138] VER binkd/1.1a-111/Linux binkp/1.1
    - 11:29 [1138] TRF 0 55671
    + 11:29 [1138] Remote has 0b of mail and 55671b of files for us
    ? 11:29 [1138] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*)

    next poll it's still the same...

    - 11:31 [1146] VER binkd/1.1a-111/Linux binkp/1.1
    - 11:31 [1146] TRF 0 55671
    + 11:31 [1146] Remote has 0b of mail and 55671b of files for us
    ? 11:31 [1146] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*)

    until some mail is exchanged:

    - 11:37 [1159] TRF 0 55671
    + 11:37 [1159] Remote has 0b of mail and 55671b of files for us
    + 11:37 [1159] sending /ftn/packets/f04ce901.pkt as f04ce901.pkt (1064)
    11:37 [1159] bzip2 mode is on for f04ce901.pkt
    ? 11:37 [1159] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*)
    11:37 [1159] Compressed 1064 bytes to 770 for f04ce901.pkt, ratio 72.4%

    next poll:

    - 11:37 [1172] TRF 0 0
    + 11:37 [1172] Remote has 0b of mail and 0b of files for us


    Is this a bug?

    ---
    * Origin: (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oli on Saturday, January 02, 2021 12:30:18
    Hi Oli,

    On 2021-01-02 11:41:08, you wrote to All:

    How does file skipping work in Binkd? I'm on a bad/slow mobile
    connection
    at the moment and only want to receive mails, no nodelist updates. So I put

    skip all !0 DAILYUTF.*

    in binkd.cfg, but the file doesn't seem to get deleted on the other side:

    - 11:28 [1138] VER binkd/1.1a-111/Linux binkp/1.1
    - 11:29 [1138] TRF 0 55671
    + 11:29 [1138] Remote has 0b of mail and 55671b of files for us
    ? 11:29 [1138] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*)

    next poll it's still the same...

    - 11:31 [1146] VER binkd/1.1a-111/Linux binkp/1.1
    - 11:31 [1146] TRF 0 55671
    + 11:31 [1146] Remote has 0b of mail and 55671b of files for us
    ? 11:31 [1146] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*)

    until some mail is exchanged:

    - 11:37 [1159] TRF 0 55671
    + 11:37 [1159] Remote has 0b of mail and 55671b of files for us
    + 11:37 [1159] sending /ftn/packets/f04ce901.pkt as f04ce901.pkt (1064)
    11:37 [1159] bzip2 mode is on for f04ce901.pkt
    ? 11:37 [1159] skipping DAILYUTF.Z02 (destructive, 55671 byte(s), mask DAILYUTF.*) 11:37 [1159] Compressed 1064 bytes to 770 for f04ce901.pkt, ratio 72.4%

    Strange, on this end they look the same regarding the DAILYUTF file. This is what a grep on DAILYUTF.Z02 shows:

    + 02 Jan 08:50:06 [31959] sending /home/fido/fileareas/dailyutf/DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 08:50:06 [31959] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 08:50:14 [31959] remote already has DAILYUTF.Z02
    + 02 Jan 11:26:54 [6706] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:26:54 [6706] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:26:54 [6706] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:27:01 [6706] remote already has DAILYUTF.Z02
    + 02 Jan 11:28:29 [6721] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:28:29 [6721] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:28:29 [6721] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:28:30 [6721] remote already has DAILYUTF.Z02
    + 02 Jan 11:29:00 [6726] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:29:00 [6726] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:29:00 [6726] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:29:01 [6726] remote already has DAILYUTF.Z02
    + 02 Jan 11:31:01 [6776] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:31:01 [6776] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:31:01 [6776] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:31:01 [6776] remote already has DAILYUTF.Z02
    + 02 Jan 11:37:33 [7087] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:37:33 [7087] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:37:33 [7087] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:37:34 [7087] remote already has DAILYUTF.Z02

    next poll:

    - 11:37 [1172] TRF 0 0
    + 11:37 [1172] Remote has 0b of mail and 0b of files for us

    Is this a bug?

    Maybe binkd gives up after a couple of retries? It seems to remember the transmit status of the file between sessions...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Wilfred van Velzen on Saturday, January 02, 2021 14:38:00
    Wilfred wrote (2021-01-02):

    Strange, on this end they look the same regarding the DAILYUTF file. This is what a grep on DAILYUTF.Z02 shows:
    [...]
    + 02 Jan 11:37:33 [7087] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:37:33 [7087] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:37:33 [7087] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:37:34 [7087] remote already has DAILYUTF.Z02

    next poll:

    - 11:37 [1172] TRF 0 0
    + 11:37 [1172] Remote has 0b of mail and 0b of files for us

    Is this a bug?

    Maybe binkd gives up after a couple of retries? It seems to remember the transmit status of the file between sessions...

    That's weird/interesting. I removed the skip line in binkd.cfg and none of the skipped files is offered anymore (at least it doesn't show up in my log). Are there still in your outbound for my system? I thought destructive would mean that they are deleted from the remote outbound.

    ---
    * Origin: (2:280/464.47)
  • From Tommi Koivula@2:221/1.1 to Oli on Saturday, January 02, 2021 16:43:38
    Hi Oli.

    02 Jan 21 14:38:00, you wrote to Wilfred van Velzen:

    Wilfred wrote (2021-01-02):

    Strange, on this end they look the same regarding the DAILYUTF file. This
    is what a grep on DAILYUTF.Z02 shows:

    [...]

    + 02 Jan 11:37:33 [7087] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:37:33 [7087] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:37:33 [7087] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:37:34 [7087] remote already has DAILYUTF.Z02

    next poll:

    - 11:37 [1172] TRF 0 0
    + 11:37 [1172] Remote has 0b of mail and 0b of files for us

    Is this a bug?

    Maybe binkd gives up after a couple of retries? It seems to remember the
    transmit status of the file between sessions...

    That's weird/interesting. I removed the skip line in binkd.cfg and none of the skipped files is offered
    anymore (at least it doesn't show up in my log). Are there still in your outbound for my system? I
    thought destructive would mean that they are deleted from the remote outbound.

    How does this "hold-skipped" work? Does it hold skipped files no matter what?

    === Cut ===
    #
    # hold-skipped <S>
    # Binkd will hold for S seconds all mail skipped by a node. (Def. -- 1h)
    #
    #hold-skipped 1h
    === Cut ===

    'Tommi

    ---
    * Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)
  • From Wilfred van Velzen@2:280/464 to Oli on Saturday, January 02, 2021 16:42:56
    Hi Oli,

    On 2021-01-02 14:38:00, you wrote to me:

    Strange, on this end they look the same regarding the DAILYUTF file.
    This is what a grep on DAILYUTF.Z02 shows:
    [...]
    + 02 Jan 11:37:33 [7087] Status is 'DAILYUTF.Z02 55671 1609542303'
    + 02 Jan 11:37:33 [7087] sending DAILYUTF.Z02 as DAILYUTF.Z02 (55671)
    02 Jan 11:37:33 [7087] bzip2 mode is on for DAILYUTF.Z02
    + 02 Jan 11:37:34 [7087] remote already has DAILYUTF.Z02

    next poll:

    - 11:37 [1172] TRF 0 0
    + 11:37 [1172] Remote has 0b of mail and 0b of files for us

    Is this a bug?

    Maybe binkd gives up after a couple of retries? It seems to remember
    the transmit status of the file between sessions...

    That's weird/interesting. I removed the skip line in binkd.cfg and none of the skipped files is offered anymore (at least it doesn't show up in my log). Are there still in your outbound for my system? I thought destructive
    would mean that they are deleted from the remote outbound.

    It wasn't in the .flo file for your system when I checked just before I sent my previous message around 12:30...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Saturday, January 02, 2021 16:46:25
    Hi Tommi,

    On 2021-01-02 16:43:38, you wrote to Oli:

    Maybe binkd gives up after a couple of retries? It seems to
    remember the transmit status of the file between sessions...

    That's weird/interesting. I removed the skip line in binkd.cfg and
    none of the skipped files is offered anymore (at least it doesn't show
    up in my log). Are there still in your outbound for my system? I
    thought destructive would mean that they are deleted from the remote
    outbound.

    How does this "hold-skipped" work? Does it hold skipped files no matter what?

    === Cut ===
    #
    # hold-skipped <S>
    # Binkd will hold for S seconds all mail skipped by a node. (Def. -- 1h)
    #
    #hold-skipped 1h
    === Cut ===

    I have it set to 8h...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)