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

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

 MD> .bsy and .csy files protect BSO (bink style outbound) only, a filebox
 MD> 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...

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

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

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