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

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

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

 MD> 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...

 ml>> but technically speaking, we always use move...

 MD> Well, I meant that in Windows it is called ren (rename) and in Unices
 MD> 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...

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

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

 MD> I used FrontDoor more than 20 years ago so I remember nothing about it
 MD> 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 ;)

 MD> The following is my understanding of binkd.

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

 MD> So if we want to have a possibility to add messages to a mail bundle
 MD> we should use BSO with its semaphore mechanism. Thus the absence of
 MD> semaphores (or flag files) in fileboxes is not a mistake but a part of
 MD> 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!
---