I'm currently trying to work out why there may be issues polling a system running BinkD 1.1a-27/Win64 binkp/1.1

When I poll using my Mystic BBS I get the following

[snip]

Jan 06 19:49:43 FIDOPOLL Version 1.12 A38 2018/01/01
Jan 06 19:49:43 Scanning 21:1/158
Jan 06 19:49:43 Queued 73 files (268271346 bytes) to 21:1/158
Jan 06 19:49:43 Polling BINKP node 21:1/158 by IPV4
Jan 06 19:49:43 Connecting to starlight.altimit.nl
Jan 06 19:49:44 Connected
Jan 06 19:49:44 S: NUL SYS fsxHUB [fsxNet WHQ]
Jan 06 19:49:44 S: NUL ZYZ Paul Hayton
Jan 06 19:49:44 S: NUL VER Mystic/1.12A38 binkp/1.0
Jan 06 19:49:44 S: ADR 21:1/100@fsxnet 21:1/3@fsxnet 21:1/2@fsxnet 21:1/0@fsxnet 21:0/0@fsxnet
Jan 06 19:49:45 C: NUL OPT CRAM-MD5-95c9157f3809df6d75e119bf4116faee
Jan 06 19:49:45 C: NUL SYS Starlight
Jan 06 19:49:45 System Starlight
Jan 06 19:49:45 C: NUL ZYZ Lars van Dijk
Jan 06 19:49:45 SysOp Lars van Dijk
Jan 06 19:49:45 C: NUL LOC Beek en Donk
Jan 06 19:49:45 Location Beek en Donk
Jan 06 19:49:45 C: NUL NDL 115200,TCP,BINKP
Jan 06 19:49:45 Info NDL 115200,TCP,BINKP
Jan 06 19:49:45 C: NUL TIME Sat, 6 Jan 2018 07:49:54 +0100
Jan 06 19:49:45 Info TIME Sat, 6 Jan 2018 07:49:54 +0100
Jan 06 19:49:45 C: NUL VER binkd/1.1a-27/Win64 binkp/1.1
Jan 06 19:49:45 Mailer binkd/1.1a-27/Win64 binkp/1.1
Jan 06 19:49:45 C: ADR 2:280/2020@fidonet 21:1/158@fsxnet
Jan 06 19:49:45 S: PWD
Jan 06 19:49:45 C: BSY Secure AKA 21:1/100@fsxnet busy
Jan 06 19:49:45 Authorization failed

[snip]

Earlier logs sent to me by Lars show this sort of thing at his end.

[snip]

- 25 Dec 09:20:39 [3404] incoming from 219.89.83.33 (58904)
25 Dec 09:20:39 [3404] started server #2, id=500
25 Dec 09:20:39 [3456] binkp init done, socket # is 580
+ 25 Dec 09:20:39 [3456] incoming session with 219-89-83-33.adsl.xtra.co.nz [219.89.83.33]
25 Dec 09:20:39 [3456] send message NUL OPT CRAM-MD5-eec921f5739d64f825eb22d47b8f18ee
25 Dec 09:20:39 [3456] send message NUL SYS Starlight
25 Dec 09:20:39 [3456] send message NUL ZYZ Lars van Dijk
25 Dec 09:20:39 [3456] send message NUL LOC Beek en Donk
25 Dec 09:20:39 [3456] send message NUL NDL 115200,TCP,BINKP
25 Dec 09:20:39 [3456] send message NUL TIME Mon, 25 Dec 2017 09:20:39 +0100
25 Dec 09:20:39 [3456] send message NUL VER binkd/1.1a-27/Win64 binkp/1.1
25 Dec 09:20:39 [3456] send message ADR 2:280/2020@fidonet 21:1/158@fsxnet
25 Dec 09:20:39 [3456] rcvd msg NUL SYS fsxHUB [fsxNet WHQ]
- 25 Dec 09:20:39 [3456] SYS fsxHUB [fsxNet WHQ]
25 Dec 09:20:39 [3456] rcvd msg NUL ZYZ Paul Hayton
- 25 Dec 09:20:39 [3456] ZYZ Paul Hayton
25 Dec 09:20:39 [3456] rcvd msg NUL VER Mystic/1.12A37 binkp/1.0
- 25 Dec 09:20:39 [3456] VER Mystic/1.12A37 binkp/1.0
25 Dec 09:20:39 [3456] remote uses binkp v.1.0
25 Dec 09:20:39 [3456] rcvd msg ADR 21:1/100@fsxnet 21:1/3@fsxnet 21:1/2@fsxnet 21:1/0@fsxnet 21:0/0@fsxnet
25 Dec 09:20:39 [3456] Can't create c:/fidonet/binkd/ftn\outb\00010064.bsy: File exists
+ 25 Dec 09:20:39 [3456] addr: 21:1/100@fsxnet (n/a or busy)
? 25 Dec 09:20:39 [3456] Secure AKA 21:1/100@fsxnet busy, drop the session
25 Dec 09:20:39 [3456] send message BSY Secure AKA 21:1/100@fsxnet busy
+ 25 Dec 09:20:39 [3456] done (?, failed, S/R: 0/0 (0/0 bytes))
25 Dec 09:20:39 [3456] processing kill list
25 Dec 09:20:39 [3456] binkp deinit done...
25 Dec 09:20:39 [3456] session closed, quitting...
25 Dec 09:20:39 [3456] downing server...


[snip]

Lars suspected it may be a permissions thing at his end with respect how busy semaphores are being created and perhaps not removed correctly?

This from a recent email.

[snip]

Hi Paul,

I just did:

Polling:

C:\FidoNet\BinkD>binkd64.exe -p -P 21:1/100 binkd.cfg
$ -d 21:1/100@fsxnet busy
14:48 [4952] idle

outbox contains:
01-01-2018 14:48 <DIR> .
01-01-2018 14:48 <DIR> ..
01-01-2018 14:44 6 00000000.bsy
01-01-2018 14:44 6 00010000.bsy
01-01-2018 14:44 6 00010002.bsy
01-01-2018 14:44 6 00010003.bsy
01-01-2018 14:44 6 00010064.bsy
01-01-2018 14:48 0 00010064.dlo
27-12-2017 13:45 16 0118138b.try


even when the service is stopped.

All files contain "768" except the last one which reads:
"
CONNECT/BND"

I doubt you find anything in the logs. If you like I could remove the bsy
files and try again.

[snip]

Does anyone have any thoughts?

I'm 99% sure we're fine for session password details and he's flying the correct AKA for his fsxNet node.

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello Paul!

06 Jan 18 19:55, you wrote to All:

outbox contains:
01-01-2018 14:48 <DIR> .
01-01-2018 14:48 <DIR> ..
01-01-2018 14:44 6 00000000.bsy
01-01-2018 14:44 6 00010000.bsy
01-01-2018 14:44 6 00010002.bsy
01-01-2018 14:44 6 00010003.bsy
01-01-2018 14:44 6 00010064.bsy
01-01-2018 14:48 0 00010064.dlo
27-12-2017 13:45 16 0118138b.try

Remove the stale bsy files.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hi Kees,

On 2018-01-06 10:34:42, you wrote to Paul Hayton:

outbox contains:
01-01-2018 14:48 <DIR> .
01-01-2018 14:48 <DIR> ..
01-01-2018 14:44 6 00000000.bsy
01-01-2018 14:44 6 00010000.bsy
01-01-2018 14:44 6 00010002.bsy
01-01-2018 14:44 6 00010003.bsy
01-01-2018 14:44 6 00010064.bsy
01-01-2018 14:48 0 00010064.dlo
27-12-2017 13:45 16 0118138b.try

Remove the stale bsy files.

binkd has a setting for that, to do it automatically:

# Remove old .bsy/.csy files (If some are left after a system crash). It would # be wise to set this to 12h on almost any system. (Note that binkd always
# touches .bsy's/.csy's for active sessions)
#
# kill-old-bsy is OFF by default.
#
kill-old-bsy 4h


Bye, Wilfred.

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

06 Jan 18 10:34:42, Kees van Eeten wrote to you:

outbox contains:
01-01-2018 14:48 <DIR> .
01-01-2018 14:48 <DIR> ..
01-01-2018 14:44 6 00000000.bsy
01-01-2018 14:44 6 00010000.bsy
01-01-2018 14:44 6 00010002.bsy
01-01-2018 14:44 6 00010003.bsy
01-01-2018 14:44 6 00010064.bsy
01-01-2018 14:48 0 00010064.dlo
27-12-2017 13:45 16 0118138b.try

Remove the stale bsy files.

Also set up 'kill-old-bsy' in your binkd.conf:

=== Cut ===
#
# Remove old .bsy/.csy files (If some are left after a system crash). It would # be wise to set this to 12h on almost any system. (Note that binkd always
# touches .bsy's/.csy's for active sessions)
#
# kill-old-bsy is OFF by default.
#
=== Cut ===

I have it set to 1h.

'Tommi

---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

On 01/06/18, Wilfred van Velzen pondered and said...

binkd has a setting for that, to do it automatically:

# Remove old .bsy/.csy files (If some are left after a system crash). It would # be wise to set this to 12h on almost any system. (Note that
binkd always # touches .bsy's/.csy's for active sessions)
#
# kill-old-bsy is OFF by default.
#
kill-old-bsy 4h

Is the use of 4h OK in the syntax or do I need to state ,minutes instead?

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hi Paul,

On 2018-01-07 08:59:29, you wrote to me:

binkd has a setting for that, to do it automatically:

# Remove old .bsy/.csy files (If some are left after a system crash).
It would # be wise to set this to 12h on almost any system. (Note that
binkd always # touches .bsy's/.csy's for active sessions)
#
# kill-old-bsy is OFF by default.
#
kill-old-bsy 4h

Is the use of 4h OK in the syntax or do I need to state ,minutes instead?

It should be. I use that notation for more than one setting. It's even stated in the example config:

# Suffixes for time intervals are w for weeks, d for days,
# h for hours, m for minutes, s or no suffix for seconds.
# You can mix the suffixes, i.e. 1d12h is the same as 36h.


Bye, Wilfred.

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

Hi! Paul,

On 01/07/2018 05:59 AM, you wrote to Wilfred van Velzen:

kill-old-bsy 4h

Is the use of 4h OK in the syntax or do I need to state ,minutes instead?

FWIW, I've been using "kill-old-bsy 43200 " on any binkD config for at least the last 15 years.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)

Hello Tommi!

06 Jan 18 12:51, you wrote to Paul Hayton:

06 Jan 18 10:34:42, Kees van Eeten wrote to you:

outbox contains:
01-01-2018 14:48 <DIR> .
01-01-2018 14:48 <DIR> ..
01-01-2018 14:44 6 00000000.bsy
01-01-2018 14:44 6 00010000.bsy
01-01-2018 14:44 6 00010002.bsy
01-01-2018 14:44 6 00010003.bsy
01-01-2018 14:44 6 00010064.bsy
01-01-2018 14:48 0 00010064.dlo
27-12-2017 13:45 16 0118138b.try

Remove the stale bsy files.

Also set up 'kill-old-bsy' in your binkd.conf:

=== Cut ===
#
# Remove old .bsy/.csy files (If some are left after a system crash). It would # be wise to set this to 12h on almost any system. (Note that binkd always # touches .bsy's/.csy's for active sessions) # # kill-old-bsy is OFF by default. #
=== Cut ===

I have it set to 1h.

That does not help you now, if a session has crashed and you want to try
it again. If one not aware of the auto removal, one may wonder why
thing sometimes work and sometimes don't.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

On 2018 Jan 07 08:59:28, you wrote to Wilfred van Velzen:

kill-old-bsy 4h

Is the use of 4h OK in the syntax or do I need to state ,minutes instead?

i forget where i found it but m, h, d and w seem to work... minutes, hours, days, and weeks...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Heisenberg may have slept here.
---
* Origin: (1:3634/12.73)

On 2018 Jan 07 08:17:16, you wrote to Paul Hayton:

kill-old-bsy 4h

Is the use of 4h OK in the syntax or do I need to state ,minutes
instead?

FWIW, I've been using "kill-old-bsy 43200 " on any binkD config for at least the last 15 years.

that's 43200 seconds ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Today's gas prices give BushCo's Saudi OPEC pals wet dreams.
---
* Origin: (1:3634/12.73)

Hi! mark,

On Sat, 06 Jan 18, you wrote to me:

FWIW, I've been using "kill-old-bsy 43200 " on any
binkD config for at least the last 15
years.

that's 43200 seconds ;)

Damned right! It's so big & beautiful. ;-)

(It also means I've never been plagued by .bsy file sillyness.)

Cheers,
Paul.

--- Paul's Win98SE VirtualBox
* Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)

06 Jan 18 18:08:38, you wrote to me:

Remove the stale bsy files.

Also set up 'kill-old-bsy' in your binkd.conf:

=== Cut ===
#
# Remove old .bsy/.csy files (If some are left after a system crash). It
would # be wise to set this to 12h on almost any system. (Note that binkd
always # touches .bsy's/.csy's for active sessions) # # kill-old-bsy is
OFF by default. #
=== Cut ===

I have it set to 1h.

That does not help you now, if a session has crashed and you want to try
it again. If one not aware of the auto removal, one may wonder why
thing sometimes work and sometimes don't.

Of course.

When troubleshooting, always delete all .bsy, .try and .hld first in every bso subdir.

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

On 2018 Jan 07 10:47:00, you wrote to me:

FWIW, I've been using "kill-old-bsy 43200 " on any binkD config for
at least the last 15 years.

that's 43200 seconds ;)

Damned right! It's so big & beautiful. ;-)

hehehe... it is also

720m
12h

(It also means I've never been plagued by .bsy file sillyness.)

i've not had any problems with it, either... other software has, though... in fact, the only time i've seen any residual bsy files has been when something has caused the system to reboot while there were transfers taking place... my boot time cleanup stuff takes care of them and numerous others, though...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Don't take life too seriously. You'll never get out of it alive.
---
* Origin: (1:3634/12.73)

On 2018 Jan 07 11:16:52, you wrote to Kees van Eeten:

That does not help you now, if a session has crashed and you want to
try it again. If one not aware of the auto removal, one may wonder
why thing sometimes work and sometimes don't.

Of course.

When troubleshooting, always delete all .bsy, .try and .hld first in
every bso subdir.

i never worry about the try files... they contain the last connection result and don't seem to do anything else... bsy and hld, sure... remove them and see if they generate the hld again... then look at the try to see why the hld was generated... or just read the log because the same info is in there, too...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'm in shape ... round's a shape isn't it?
---
* Origin: (1:3634/12.73)

07 Jan 18 08:48, mark lewis wrote to Tommi Koivula:

When troubleshooting, always delete all .bsy, .try and .hld first in
every bso subdir.

i never worry about the try files...

I erase them as well as the .hld files, because sometimes .try's are left behind.

Right now this is what I have in the zone1 bso:

11.11.17 9.48 16 124 01050026.try
25.11.17 22.07 22 124 00110000.try
26.11.17 9.26 16 124 00990000.try
26.11.17 10.02 22 124 00110002.try
26.11.17 11.06 23 124 008c0000.try
1.12.17 8.58 23 124 008c0001.try
10.12.17 5.33 34 124 012a0000.try
10.12.17 5.56 16 124 012a0019.try
19.12.17 7.43 16 124 00010000.try
30.12.17 14.37 29 124 00d502d0.try
30.12.17 14.37 16 124 00d50000.try
7.01.18 23.37 16 124 01400077.try
7.01.18 23.51 16 124 0013000a.try
7.01.18 23.57 16 124 014000db.try

'Tommi

--- GoldED+/EMX 1.1.5-b20170303
* Origin: f10.n221.z2.fidonet.fi (2:221/10)

On 2018 Jan 07 23:55:58, you wrote to me:

When troubleshooting, always delete all .bsy, .try and .hld first in
every bso subdir.

i never worry about the try files...

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed to determine the
last connection result to that system...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Don't be sexist. Chicks hate it.
---
* Origin: (1:3634/12.73)

07 Jan 18 17:36:46, you wrote to me:

When troubleshooting, always delete all .bsy, .try and .hld first in
every bso subdir.

i never worry about the try files...

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed to

determine

the last connection result to that system...

What is the value of this information if it is 1 year old?

'Tommi

---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

Hi Tommi,

On 08 Jan 18 08:34, Tommi Koivula wrote to mark lewis:
about: "Connection Problems":

AFAIK, .try files are always left behind... they can be parsed to
determine the last connection result to that system...

What is the value of this information if it is 1 year old?

You know you tried connecting to that system 1 year ago, and know what the result was. ;)

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

Hi! Tommi,

On 01/08/2018 04:34 PM, you wrote to mark lewis:

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed to

determine

the last connection result to that system...

What is the value of this information if it is 1 year old?

US$0.42?

:-D

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)

08 Jan 18 17:10:26, you wrote to me:

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed
to determine the last connection result to that system...

What is the value of this information if it is 1 year old?

US$0.42?

Each? I'll start collecting .try's right now! Where can I cash them in january 2019? Can I have EUR instead of toy money?

:-D

:-D

'Tommi

---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

Hi! Tommi,

On 01/08/2018 05:26 PM, you wrote:

What is the value of this information if it is 1 year old?

US$0.42?

Each? I'll start collecting .try's right now! Where can I cash them in january 2019? Can I have EUR instead of toy money?

:-D

:-D

They can be redeemed right here! I'll do it. Slip me AUD$20.00 just a week ahead of time. ;-)

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)

On 2018 Jan 08 08:34:16, you wrote to me:

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed to
determine the last connection result to that system...

What is the value of this information if it is 1 year old?

i suppose it has the same value if it is 10 years old or 1 hour old :shrug:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Experience is such a good teacher because it's always on the job!
---
* Origin: (1:3634/12.73)

Hello Tommi!

08 Jan 18 09:26, you wrote to Paul Quinn:

US$0.42?

Each? I'll start collecting .try's right now! Where can I cash them in january 2019? Can I have EUR instead of toy money?

You should even be able to charge premium prices for them. After all, they're 100% recycled! :-D

Andrew

--- GoldED+/LNX 1.1.5-b20170303
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

08 Jan 18 07:38:56, you wrote to me:

I erase them as well as the .hld files, because sometimes .try's are
left behind.

AFAIK, .try files are always left behind... they can be parsed to
determine the last connection result to that system...

What is the value of this information if it is 1 year old?

i suppose it has the same value if it is 10 years old or 1 hour old

:shrug:

There are 'hold' and 'try' settings. I can understand if binkd reads the .try file in one hour, but after 1 or 10 years they are orphan files.

I think .try's should be cleaned by binkd as well as the .hld's.

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

08 Jan 18 06:58:54, you wrote to me:

US$0.42?

Each? I'll start collecting .try's right now! Where can I cash them in
january 2019? Can I have EUR instead of toy money?

You should even be able to charge premium prices for them. After all, they're 100% recycled! :-D

So they are trash. Damn! :-D

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

On 2018 Jan 08 18:27:12, you wrote to me:

AFAIK, .try files are always left behind... they can be parsed to
determine the last connection result to that system...

What is the value of this information if it is 1 year old?

i suppose it has the same value if it is 10 years old or 1 hour old
:shrug:

There are 'hold' and 'try' settings. I can understand if binkd reads
the .try file in one hour, but after 1 or 10 years they are orphan
files.

I think .try's should be cleaned by binkd as well as the .hld's.

then what's the use of having them in the first place? or are you saying that they should only live as long as the hld files? that would mean the try files will never be created for successful outbound connections??

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'm not crazy. I'm just mentally overstimulated.
---
* Origin: (1:3634/12.73)

08 Jan 18 13:16:34, you wrote to me:

I think .try's should be cleaned by binkd as well as the .hld's.

then what's the use of having them in the first place? or are you saying that they should only live as long as the hld files? that would mean the try files will never be created for successful outbound connections??

I don't know exactly how binkd uses them, but it sure is not nice if I send you
crashmail once and after that there will be a .try forever in the bso.

I just made a poll from my point. Now I have:

Directory of C:\bbs\bso\fido.001\*try

8.01.2018 23:21 16 0e32000c.try

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

Hello Tommi,

On Monday January 08 2018 23:17, you wrote to mark lewis:

I think .try's should be cleaned by binkd as well as the .hld's.

then what's the use of having them in the first place? or are you
saying that they should only live as long as the hld files? that
would mean the try files will never be created for successful
outbound connections??

I don't know exactly how binkd uses them, but it sure is not nice if I send you crashmail once and after that there will be a .try forever in
the bso.

I agree with you. An option in binkd to clear old .try's would be nice. But I have a daily routine to delete old files, so I think I will just doe it there.

I just made a poll from my point. Now I have:

Directory of C:\bbs\bso\fido.001\*try

8.01.2018 23:21 16 0e32000c.try

And it stays there forever...

Ask Wilfred for Delolder...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)