Hello folks,

I've got a second time a 'permission denied' error, while binkd want's to start
a filetransfer.
Maybe someone can help to solve this.

the first part, was to show, that the file comes in;
the second part schows the error.

=##= Anfang "binkderr.txt" =##=
+ 28 Nov 08:13:02 [27682] smnk2429.zip -> e:\dbahn\mailer\protect\smnk2429.zip + 28 Nov 08:13:02 [27682] rcvd: smnk2429.zip (52059372, 68319.39 CPS, 2:24/902@fidonet)
- 28 Nov 08:13:02 [27682] receiving TK847019.TIC (1411 byte(s), off 0)

[....]


- 28 Nov 08:13:25 [27729] OPT EXTCMD CRYPT GZ BZ2
+ 28 Nov 08:13:25 [27729] Remote supports EXTCMD mode
+ 28 Nov 08:13:25 [27729] Remote requests CRYPT mode
+ 28 Nov 08:13:25 [27729] Remote supports GZ mode
+ 28 Nov 08:13:25 [27729] Remote supports BZ2 mode
+ 28 Nov 08:13:25 [27729] pwd protected session (MD5)
- 28 Nov 08:13:25 [27729] session in CRYPT mode
? 28 Nov 08:13:25 [27729] start_file_transfer: F:\DBFile\GFD\NET\WWW\smnk2429.zip: Permission denied
+ 28 Nov 08:13:25 [27729] sending E:\dbahn\mailer\hold\TK849606.TIC as TK849606.TIC (1523)
+ 28 Nov 08:13:25 [27729] sent: E:\dbahn\mailer\hold\TK849606.TIC (1523, 1523.00 CPS, 2:240/9190@fidonet)
=##= Ende "binkderr.txt" =##=


Binkd is compiled with this flags:
=##= Anfang "binkdvv.txt" =##=
Binkd 1.1a-95 (Nov 11 2017 19:18:31/OS2)
Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
Facilities: fts5004 rfc2553emu
=##= Ende "binkdvv.txt" =##=

with this compiler:

=##= Anfang "compiler.txt" =##=
Compiler:
Known predefined macroses list:
__OS2__ __GNUC__ __EMX__ __32BIT__ __MT__ __STDC__

Some values:
__GNUC__=3 (0x3); __GNUC_MINOR__=3 (0x3)
__VERSION__=3.3.5 (Bird Build 2012-03-23 03:21 (csd5))
__STDC__=1 (0x1);
=##= Ende "compiler.txt" =##=


Bye/2 Torsten

... MAILBOX: up 10d 1h 41m load: 29 proc, 133 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

28 Nov 17 19:43, you wrote to Alle:

I've got a second time a 'permission denied' error, while binkd want's
to start a filetransfer. Maybe someone can help to solve this.

I haven't seen that happening, searched the logs, nothing found like that.

Is it possible that some other program has the file open? Bbs, another mailer session, file processor...?

Binkd 1.1a-95 (Nov 11 2017 19:18:31/OS2)
Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
Facilities: fts5004 rfc2553emu

__VERSION__=3.3.5 (Bird Build 2012-03-23 03:21 (csd5))

I'm currently running:

Binkd 1.1a-95 (Oct 20 2017 01:00:22/OS2)
Compilation flags: gcc (klibc), zlib, bzlib2, https, ntlm, amiga_4d_outbound, bwlim.
Facilities: fts5004 rfc2553emu

It has been compiled with

gcc version 3.3.5 (Bird Build 2014-10-26 18:53 (csd6))

Bye/2 Torsten

'Tommi

---
* Origin: ================================== (2:221/360.10)

Hallo Tommi!

29.11.2017 21:10, Tommi Koivula schrieb an Torsten Bamberg:

Is it possible that some other program has the file open? Bbs, another mailer session, file processor...?

Nothing like that. Also JFS should been finished storing the file after 23 seconds.

__VERSION__=3.3.5 (Bird Build 2012-03-23 03:21 (csd5))

gcc version 3.3.5 (Bird Build 2014-10-26 18:53 (csd6))

Hm... I'm updating gcc to csd6.
Then I take a look at this again.

'Tommi

Bye/2 Torsten

... MAILBOX: up 11d 4h 01m load: 28 proc, 132 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

On 2017 Nov 29 21:10:52, you wrote to Torsten Bamberg:

I've got a second time a 'permission denied' error, while binkd
want's to start a filetransfer. Maybe someone can help to solve this.

I haven't seen that happening, searched the logs, nothing found like that.

Is it possible that some other program has the file open? Bbs, another mailer session, file processor...?

that's what i was wondering... i had something the other week with a huge file being placed into a filebox... binkd scanned and saw the file in the box before
the move was complete...

)\/(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 got everything but the part after "Now listen closely".
---
* Origin: (1:3634/12.73)

Hallo mark!

29.11.2017 16:36, mark lewis schrieb an Tommi Koivula:

that's what i was wondering... i had something the other week with a
huge file being placed into a filebox... binkd scanned and saw the
file in the box before the move was complete...

Strange...
Usually the file-ticer generates the flowfile for binkd after file transfer and
after generating the tic.

What sort of fileticer do you use?

)\/(ark

Bye/2 Torsten

... MAILBOX: up 0d 2h 50m load: 29 proc, 132 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

On 2017 Nov 29 23:41:38, you wrote to me:

that's what i was wondering... i had something the other week with a
huge file being placed into a filebox... binkd scanned and saw the
file in the box before the move was complete...

Strange...
Usually the file-ticer generates the flowfile for binkd after file

transfer

and after generating the tic.

What sort of fileticer do you use?

i use allfix but it wasn't involved in this... in this case, it was a script file copying files from the central procesing area's outbound to the individual
fileboxes for those that connect here via binkp... the file being copied was on a physically different drive than the the fileboxes so a rename wouldn't work...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Worry is the interest paid on Trouble, before it is due.
---
* Origin: (1:3634/12.73)

Hi! mark,

On 11/30/2017 09:14 AM, you wrote to Torsten Bamberg:

the file being copied was on a physically different drive than the
the fileboxes so a rename wouldn't work...

Have you tried using a [insert addressee's hex codes].Bsy file in the outbound for the duration of the file move, with one of your scripts? Uh-oh, oh, you haven't. ;)

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 2017 Nov 30 11:49:06, you wrote to me:

the file being copied was on a physically different drive than the
the fileboxes so a rename wouldn't work...

Have you tried using a [insert addressee's hex codes].Bsy file in the outbound for the duration of the file move, with one of your scripts? Uh-oh, oh, you haven't. ;)

actually, yes, my scripts do generally create and manage those but not all of the tools i use know what a bsy file is... one i can tell to skip a system if a
certain file exists (like a bsy file) but it doesn't create them when it is moving things around... it is not a BSO tool and doesn't care about outbounds or semaphores... its job is solely to move files from one place to another based on the destination address...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Pornography? We don't even have a pornograph!
---
* Origin: (1:3634/12.73)

Hello mark,

On Wed Nov 29 2017 22:08:42, mark lewis wrote to Paul Quinn:

actually, yes, my scripts do generally create and manage those but not
all of the tools i use know what a bsy file is... one i can tell to
skip a system if a certain file exists (like a bsy file) but it
doesn't create them when it is moving things around... it is not a BSO tool and doesn't care about outbounds or semaphores... its job is
solely to move files from one place to another based on the
destination address...

So are you saying binkd executes this script before the file is done transferring?

If so, I would agree that's probably a binkd issue. binkd should execute anything from the "exec" command AFTER said file is received, not as soon as it's aware of it.

If that's not the case, how about adding a "sleep 2" to the beginning of your script?

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

On 2017 Nov 29 21:23:26, you wrote to me:

actually, yes, my scripts do generally create and manage those but
not all of the tools i use know what a bsy file is... one i can tell
to skip a system if a certain file exists (like a bsy file) but it
doesn't create them when it is moving things around... it is not a
BSO tool and doesn't care about outbounds or semaphores... its job is
solely to move files from one place to another based on the
destination address...

So are you saying binkd executes this script before the file is done transferring?

no... binkd doesn't execute anything over here on the main system... my mail scripts were moving a large files into the fileboxes when binkd rescanned and saw the file in one of the fileboxes which it promptly tried to deliver to the remote system owning the filebox... nothing else... when the system gets busy, a copy/move that would normally take 15 to 20 seconds can take up to 60 seconds
or more...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The more you sweat in practice, the less you bleed in battle.
---
* Origin: (1:3634/12.73)

Hi Torsten,

On 28 Nov 17 19:43, Torsten Bamberg wrote to Alle:
about: "permission denied error ":

I've got a second time a 'permission denied' error, while binkd want's
to start a filetransfer. Maybe someone can help to solve this.

smnk2429.zip (52059372,

Maybe there is a 'skip' statement in the binkd config file of the receiving node, that limits file sizes?


Wilfred.

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

Hello mark,

On Thu Nov 30 2017 02:24:22, mark lewis wrote to Nicholas Boel:

So are you saying binkd executes this script before the file is
done transferring?

no... binkd doesn't execute anything over here on the main system...
my mail scripts were moving a large files into the fileboxes when
binkd rescanned and saw the file in one of the fileboxes which it
promptly tried to deliver to the remote system owning the filebox... nothing else... when the system gets busy, a copy/move that would
normally take 15 to 20 seconds can take up to 60 seconds or more...

So then you're saying that a large file was being transferred into a filebox, and binkd tried sending it out before the copy/move was finished?

Sorry man, something just doens't add up here. Whether it be your scripts, or binkd, or whatever. It's all about the story, man! ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

On 2017 Nov 30 04:07:00, you wrote to me:

So are you saying binkd executes this script before the file is done
transferring?

no... binkd doesn't execute anything over here on the main system...
my mail scripts were moving a large files into the fileboxes when
binkd rescanned and saw the file in one of the fileboxes which it
promptly tried to deliver to the remote system owning the filebox...
nothing else... when the system gets busy, a copy/move that would
normally take 15 to 20 seconds can take up to 60 seconds or more...

So then you're saying that a large file was being transferred into a filebox, and binkd tried sending it out before the copy/move was
finished?

yes...

Sorry man, something just doens't add up here. Whether it be your
scripts, or binkd, or whatever. It's all about the story, man! ;)

i gave facts from an incident that took place here that might coroborate someone else's similar situation... nothing more...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... 'Ow d'ya know she's a witch?" "She turned me into a NEWT!
---
* Origin: (1:3634/12.73)

Hallo Wilfred!

30.11.2017 10:46, Wilfred van Velzen schrieb an Torsten Bamberg:

I've got a second time a 'permission denied' error, while binkd
want's to start a filetransfer. Maybe someone can help to solve
this.
smnk2429.zip (52059372,

Maybe there is a 'skip' statement in the binkd config file of the receiving node, that limits file sizes?

Good point. :-)

But no, he has no filelimits set.
We've had much bigger filetransfers before.

A few weeks ago I've had this 'permission denied' error with an other node, while transfering our nodelist. I haven't had this error neer before. So I thought, the reason for this error might be something between moonshine and jfs
caching mismatch. But having this error a second time, is to often at my point of view. Thats the reason for asking around.

Wilfred.

Bye/2 Torsten

... MAILBOX: up 0d 18h 15m load: 29 proc, 132 threads (tbupv1.0)
--- GoldED+ 1.1.5-17
* Origin: DatenBahn BBS Hamburg (2:240/5832)

29 Nov 17 20:34:34, you wrote to me:

29.11.2017 21:10, Tommi Koivula schrieb an Torsten Bamberg:

Is it possible that some other program has the file open? Bbs, another
mailer session, file processor...?

Nothing like that. Also JFS should been finished storing the file after 23 seconds.

I noticed the time window of 23sec... Did you compare the file processor logs with binkd logs?

__VERSION__=3.3.5 (Bird Build 2012-03-23 03:21 (csd5))

gcc version 3.3.5 (Bird Build 2014-10-26 18:53 (csd6))

Hm... I'm updating gcc to csd6.
Then I take a look at this again.

I doubt it makes any difference.. But just do it anyways. :)

'Tommi

---
* Origin: telnet://v6.fidonet.fi (2:221/1)

Hello mark,

Wednesday November 29 2017, mark lewis wrote to Torsten Bamberg:

that's what i was wondering... i had something the other week
with a huge file being placed into a filebox... binkd scanned
and saw the file in the box before the move was complete...

Strange...
Usually the file-ticer generates the flowfile for binkd after
file

transfer

and after generating the tic.

What sort of fileticer do you use?

i use allfix but it wasn't involved in this... in this case, it was a script file copying files from the central procesing area's outbound
to the individual fileboxes for those that connect here via binkp...
the file being copied was on a physically different drive than the the fileboxes so a rename wouldn't work...

.bsy and .csy files protect BSO (bink style outbound) only, a filebox is not protected this way. That is why one should use an atomic operation writing to a
filebox. So if the source file is on the same drive one should use move (rename) and if the source file is on a different drive one should first copy the file to a temporary directory of a target drive and then use move (rename).

It is true for any mailer, not only for binkd.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

On 2017 Dec 02 14:01:22, you wrote to me:

i use allfix but it wasn't involved in this... in this case, it was a
script file copying files from the central procesing area's outbound
to the individual fileboxes for those that connect here via binkp...
the file being copied was on a physically different drive than the
the fileboxes so a rename wouldn't work...

.bsy and .csy files protect BSO (bink style outbound) only, a filebox
is not protected this way.

that's interesting... i was not aware of that at all and we have exclusively been using BSY when writing to and removing from fileboxes specifically to prevent dual access problems...

That is why one should use an atomic operation writing to a filebox.
So if the source file is on the same drive one should use move
(rename) and if the source file is on a different drive one should
first copy the file to a temporary directory of a target drive and
then use move (rename).

ugh... that adds another layer of complexity... but technically speaking, we always use move... it is up to the tool or OS to copy or rename as necessary...
we might have to take a closer look at the tool that has been being used ever since binkd was added to the system...

It is true for any mailer, not only for binkd.

FrontDoor doesn't have this problem... we use FD semaphores to signal FD to do or not do certain things (eg: fdnoscan.now, fdcansess.11, fdrescan.now) as well
as using semaphores similar to BSY... this is one of the reasons why we asked several years ago for more disk based semaphores to talk to and control binkd with...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You talkin' to me?
---
* Origin: (1:3634/12.73)

Hello mark,

Saturday December 02 2017, mark lewis wrote to Michael Dukelsky:

i use allfix but it wasn't involved in this... in this case, it
was a script file copying files from the central procesing
area's outbound to the individual fileboxes for those that
connect here via binkp... the file being copied was on a
physically different drive than the the fileboxes so a rename
wouldn't work...

.bsy and .csy files protect BSO (bink style outbound) only, a
filebox is not protected this way.

that's interesting... i was not aware of that at all and we have exclusively been using BSY when writing to and removing from fileboxes specifically to prevent dual access problems...

That is why one should use an atomic operation writing to a
filebox. So if the source file is on the same drive one should
use move (rename) and if the source file is on a different drive
one should first copy the file to a temporary directory of a
target drive and then use move (rename).

ugh... that adds another layer of complexity...

I see no complexity here.

but technically speaking, we always use move...

Well, I meant that in Windows it is called ren (rename) and in Unices mv (move).

it is up to the tool or OS to copy or rename as necessary... we might
have to take a closer look at the tool
that has been being used ever since binkd was added to the system...

It is true for any mailer, not only for binkd.

FrontDoor doesn't have this problem... we use FD semaphores to signal
FD to do or not do certain things (eg: fdnoscan.now, fdcansess.11, fdrescan.now) as well as using semaphores similar to BSY... this is
one of the reasons why we asked several years ago for more disk based semaphores to talk to and control binkd with...

I used FrontDoor more than 20 years ago so I remember nothing about it now... :) The following is my understanding of binkd.

Binkd author implemented two formats of outbound: Binkley style outbound and filebox. These two formats have differing purpose. Fileboxes are used for a simple file transfer. If a file has been put into a filebox then it is assumed that a mailer is free to transfer it. This simplicity is the main advantage of fileboxes. It is good for transferring regular files. The one and only demand is an atomic move of a file to filebox. Mail bundles may also be transferred in
such a way but one cannot add messages to the bundles already located in a filebox since the mailer can start transferring the bundles at any moment.

So if we want to have a possibility to add messages to a mail bundle we should use BSO with its semaphore mechanism. Thus the absence of semaphores (or flag files) in fileboxes is not a mistake but a part of philosophy.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

On 2017 Dec 03 14:23:40, you wrote to me:

That is why one should use an atomic operation writing to a filebox.
So if the source file is on the same drive one should use move
(rename) and if the source file is on a different drive one should
first copy the file to a temporary directory of a target drive and
then use move (rename).

ugh... that adds another layer of complexity...

I see no complexity here.

currently:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to BSO & fileboxes.

proposed:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to 2nd staging area on same disk as binkd.
tool moves outbound mail from 2nd staging area to BSO & fileboxes.

remember, not everyone has huge disks and fast modern machines for this stuff... the system in question has a 8Gig PATA drive broken into four 2Gig partitions and a 20Gig PATA broken into two 10Gig partitions... it was done this way years ago when OS/2 Warp 3 Connect was installed... at that time, only
the 8Gig drive was in use... there was something about partitions larger than 2Gig causing problems... i forget if it was dual-boot related or file space query related... later, when prices came down, the 20Gig was added and because it was only a data drive, extended large partitions were able to be used otherwise it would be 10 2Gig partitions...

but technically speaking, we always use move...

Well, I meant that in Windows it is called ren (rename) and in Unices
mv (move).

we have cp, mv and rn in linux but this is OS/2 where the DOS side cannot see the OS/2 side (so LFNs are only good with OS/2 native software)... 4DOS/4OS2 are in heavy use... the tool spoken above is written in C i guess and the author is not around any longer... the tool was written specifically for Frontdoor so it moves files from FD's outbound and STQ (STatic Queue) to other directories... it is possible that i may be able to share the binkd fileboxes with FD's STQ but there's still the problem is preventing binkd from scanning a
filebox that is being manipulated from outside the mailer...

It is true for any mailer, not only for binkd.

FrontDoor doesn't have this problem... we use FD semaphores to signal
FD to do or not do certain things (eg: fdnoscan.now, fdcansess.11,
fdrescan.now) as well as using semaphores similar to BSY... this is
one of the reasons why we asked several years ago for more disk based
semaphores to talk to and control binkd with...

I used FrontDoor more than 20 years ago so I remember nothing about it now... :)

i still use it today... in fact, if it wasn't for FD, i wouldn't have been one of the first ones to develop IDS/IPS rules to detect MIRAI and its variants ;)

The following is my understanding of binkd.

Binkd author implemented two formats of outbound: Binkley style
outbound and filebox. These two formats have differing purpose.
Fileboxes are used for a simple file transfer. If a file has been put
into a filebox then it is assumed that a mailer is free to transfer
it. This simplicity is the main advantage of fileboxes. It is good for transferring regular files. The one and only demand is an atomic move
of a file to filebox. Mail bundles may also be transferred in such a
way but one cannot add messages to the bundles already located in a filebox since the mailer can start transferring the bundles at any
moment.

right... that's my understanding, too, except for the part about using atomic moves into (and out of??) the fileboxes... the understanding has been that the BSY files denoted that there was a an active session OR that mail and files were being moved externally for that system so the mailer should skip doing anything with that system's files until the BSY flag is gone... i can do that for moving files out of the inbound fileboxes but have no way to create BSY files for moving outbound files without adding a lot more complexity... that completity would be breaking the tool's config file into many small ones, one for each system...

So if we want to have a possibility to add messages to a mail bundle
we should use BSO with its semaphore mechanism. Thus the absence of semaphores (or flag files) in fileboxes is not a mistake but a part of philosophy.

we're not trying to add messages to a PKT or mail bundle... who uses mail bundles these days anyway? this only has to do with moving files (of any type) into the fileboxes... the tool we use does not know anything about BSO so it cannot be used to move files into the BSO... fileboxes are the only option... i'm wary of attempting to share them between FD and binkd because the semaphores are so different and written to different places plus there are none
that we can use to tell binkd to do or not do certain things... certain things like /not/ recanning the outbound right now...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Forget technical details. Just gimmee the juicy gossip!
---
* Origin: (1:3634/12.73)

Hello mark,

Sunday December 03 2017, mark lewis wrote to Michael Dukelsky:

currently:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to BSO & fileboxes.

proposed:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to 2nd staging area on same disk as binkd.

Yes, this 2nd staging area is just a temporary outbound in terms of hpt. So since you use hpt you already have it.

tool moves outbound mail from 2nd staging area to BSO & fileboxes.

You don't have to move to temporary outbound the mail destined to BSO.

remember, not everyone has huge disks and fast modern machines for
this stuff...

You don't have to enlarge your partitions or have a faster machine. When you do
the first move, the files occupy the same extent as they do in your present scheme but just the filename is in a different directory. The second move does not change the occupied size and it is fast because the file contents is not moved. It is the file "passport" (filename and some other technical info) that is moved to a different directory.

So the only problem is your tool. If you have its sources you may change it. If
you haven't then you may use some scripting language (cmd/4DOS/4OS2, you name it) to make the second move or replace your tool with the new script completely.

BTW I don't understand why you need any special tool to move mail to outbound. You use hpt, don't you? And hpt can correctly move mail to fileboxes via temporary outbound.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

On 2017 Dec 03 22:47:12, you wrote to me:

currently:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to BSO & fileboxes.

proposed:
mail is tossed, packaged and placed in a central outbound.
tool moves outbound mail to 2nd staging area on same disk as binkd.

Yes, this 2nd staging area is just a temporary outbound in terms of hpt.

So

since you use hpt you already have it.

HPT is run on my point system... not on my main system where i was speking of...

tool moves outbound mail from 2nd staging area to BSO & fileboxes.

You don't have to move to temporary outbound the mail destined to BSO.

it is one or none... no choice...

remember, not everyone has huge disks and fast modern machines for
this stuff...

You don't have to enlarge your partitions or have a faster machine. When you do the first move, the files occupy the same extent as they do in your present scheme but just the filename is in a different directory. The second move does not change the occupied size and it is fast because the file contents is not moved. It is the file "passport" (filename and some other technical info) that is moved to a different directory.

the problem is configuring the tool to the 2nd staging area... i would do better to rewrite the tool in 4OS2...

So the only problem is your tool. If you have its sources you may
change it.

it is/was a closed tool... it may come back but that depends on if the sources are still available... FD is being ported now but i don't know if the sources to this tool are included in that porting...

If you haven't then you may use some scripting language
(cmd/4DOS/4OS2, you name it) to make the second move or replace your
tool with the new script completely.

yeah... but that code is a bit of a PITA... i do have a routine for BSO stuffs but no clean way to include it like in linux where you just source a file...

BTW I don't understand why you need any special tool to move mail to outbound. You use hpt, don't you? And hpt can correctly move mail to fileboxes via temporary outbound.

i shouldn't need HPT to do a dual move if i could use HPT on the main system...
i don't even know if there's a viable HPT for my OS/2 anyway...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Boy, I'm glad this hospital has pretty nurses :-)
---
* Origin: (1:3634/12.73)

Hi! mark,

On 12/04/2017 10:53 AM, you wrote to Michael Dukelsky:

BTW I don't understand why you need any special tool to move mail to
outbound. You use hpt, don't you? And hpt can correctly move mail to
fileboxes via temporary outbound.

i shouldn't need HPT to do a dual move if i could use HPT on the main system... i don't even know if there's a viable HPT for my OS/2 anyway...

Just me thinking out aloud...

It may be easier just modifying the binkD include file referencing the filebox (for the duration of the move 'operation' +10 minutes, before & after)?

I have a simple "string replace" DOS tool that I use on my main system (not for
binkD; for makeNL, twice every Wednesday). Maybe you've got a favourite too? :)

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 2017 Dec 04 12:20:24, you wrote to me:

BTW I don't understand why you need any special tool to move mail to
outbound. You use hpt, don't you? And hpt can correctly move mail to
fileboxes via temporary outbound.

i shouldn't need HPT to do a dual move if i could use HPT on the main
system... i don't even know if there's a viable HPT for my OS/2
anyway...

Just me thinking out aloud...

that's an idea but i don't think it would work well since we're processing mail
and files every 10 or 15 minutes now instead of once an hour like we were doing... there's a delay between the time that the change would be made and binkd would reload the file plus there's nothing that binkd does to indicate externally that it has reloaded... no external semaphore that a script file can
look for so that it knows it can go on with the process... there's not even a semaphore we can create to cause binkd to exit with a certain error level we can trap in the warpper so we can loop back and start again (eg: fdxitxxx.yyy where xxx is ANY or a specific FD task and yyy is the errorlevel to exit with)...

it doesn't happen often over here... probably because binkd is set to scan the outbound once every 60 seconds... it is only when one file move takes longer than 60 seconds when this could rear its head... it would be nice, though, if the BSY files did protect the fileboxes... that would provide at least one protection from the problem...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Before you find your handsome prince, you've got to kiss a lot of frogs. ---
* Origin: (1:3634/12.73)