Subj : permission denied error To : Michael Dukelsky From : mark lewis Date : Sun Dec 03 2017 12:39 pm 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! --- * Origin: (1:3634/12.73) .