Subj : Re-attach abandoned mail archives? To : Peter Knapper From : Johan Zwiekhorst Date : Thu Oct 16 2003 10:55 pm Hi Peter! In your message to me, dated , you wrote: JZ>> No, orphaned mail archives are shown below the ?LO file JZ>> they belong to. >PK: Not here they don't, all files that are NOT listed in a .FLO file show >PK: at the top, before any .FLO file entries. EG If there were TWO files >PK: to send to a node SOB would show 5 lines for that node - The .FLO file >PK: name against the node address, The entry in the .FLO file pointing at >PK: the first file to be moved, The Arcmail entry for the first file, The >PK: entry in the .FLO file pointing at the second file to be moved, The >PK: Arcmail entry for the second file. I've sent you an e-mail with a snapshot picture of the SOB window. It clearly shows that SOB lists the .FLO file first, then all entries in it, then the filenames destined for that node (both the ones included in the FLO and the orphaned ones). I can find no way to change that order or to have SOB identify the orphans for me. >PK: Either there is another setting that controls this or we are talking >PK: about different things. I am using SOB v1.10, however I also have >PK: v1.00 around here. I don't suppose you have a mix of v1.00 .DLL and >PK: 1.10 .EXE or something like that? I don't think so. SOB shows version 1.10 and there is no DLL -- just an EXE, a HLP and an INI. >PK: Pretty much the same here, except I am using binkd/2 0.9.5. All my >PK: background mail processing is handled by one task that serialises >PK: access to the outbound areas by the mail handling tasks (Squish, NEF, >PK: etc), and forces the programs to run individually in sequence, so >PK: processing clashes cannot ocurr. Are you able to do something like >PK: this? Yes. I have a script running in the background which uses a flag file created by BinkD to know when it has to start processing mail and files. That script checks if there are any *.?SY files in the outbound first, because then it doesn't process any mail until these are gone. When the actual processing begins, it will do nodelist segment processing first, then file distribution processing, then squish for mail processing. My Binkd/2 0.9.5a (and all versions before that) has a tendency to trap regularly. Here's the last time this happened: 09-11-2003 00:01:00 SYS3175 PID 97c8 TID 0001 Slot 004f F:\OS2\FIDONET\TCPIP\BINKD.EXE c0000005 00021d90 P1=00000001 P2=35353a32 P3=XXXXXXXX P4=XXXXXXXX EAX=00000000 EBX=002005a2 ECX=002005a2 EDX=35353a32 ESI=00000000 EDI=00000000 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:00021d90 CSACC=f0df CSLIM=ffffffff SS:ESP=0053:001454b0 SSACC=f0f3 SSLIM=ffffffff EBP=ffffffff FLG=00012246 BINKD.EXE 0002:00001d90 The Russian binkd authors, however, claim that this could be in no way responsible for flow files getting deleted and so leaving orphaned mailarchives. Nevertheless, *something* seems to be deleting flow files on my system on a regular basis (once or twice every couple of months!). Kind regards, ._|~/_ e-mail: johan@zwiekhorst.be_NOSPAM (home) web: http://www.zwiekhorst.be (personal) http://www.diskidee.be (our e-zine!) --- Maximus-CBCS v3.01 * Origin: Tripod BBS Belgium - bortaS bIr jablu'DI'reH QaQqu' nay' (2:292/100) .