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)

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)

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)

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)

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)

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)