Text 40824, 88 rader
Skriven 2006-10-05 23:57:58 av Matt Bedynek (1:106/1)
  Kommentar till text 40671 av mark lewis (1:3634/12.0)
Ärende: FNEWSN39
================
Hello mark.

04 Oct 06 10:13, you wrote to me:

 ml> yes... but i'm talking about after the tic processor has moved it into
 ml> the outbound directory for further transmission...

 MB>> What I suspect really happened here is that ross recieved the
 MB>> first copy from bjorn and likely received the copy from janis
 MB>> before the original was sent to your system?

 ml> yes... the question is how or why did the second copy overwrite the
 ml> first one... that would appear to be an error in the tic processing
 ml> program or in a script used to move the file to a filebox...

No, it makes perfect sense.  On a system without a filebox, a filearea
declaration might look like:

filearea /var/ftp/pub/fidonews ...

When a file for that area arrives, it is put inside the above directory.  BSO
or Arcmail attaches for whatever tic processor would point to the files in that
directory and the file that resides there under that name would get sent.

So, if the first file arrived, and a time lapsed such that you didnt pick up
the file before the duplicate with the same name arrived, the new one might
overwrite the one that sits in the /var/ftp/pub/fidonews directory.  So, you
would likely see two tic files, one of the original, one for the replacement
when you finally did poll.

Had you polled before the replacement was sent, you would saw the first tic and
associated archive and the second and the associate archive.  In other words,
you would have saw no errors and had your copy overwritten just like Ross did.

What changed it for you was that downtime you mentioned previously.

On a filebox setup, the same thing would / could happen.

The fact is, the situation that happened, never should.  While it would be nice
for software to handle it, there is generally never a situation in fidonet that
demanded checks.  Two files, same name, both legit as far as the software is
concerned being recieved within hours of one another.

 ml> on my system, if i carry an area in my filebase, allfix puts the file
 ml> into that area unless it has another file of the same name and i've
 ml> told it to not overwrite or replace... that puts the file into my bbs'
 ml> file areas...

 ml> now, if i also forward files in that area on to other systems, allfix
 ml> creates tic files which get placed into my TICOUT directory and the
 ml> file is copied to my TICHOLD area... it is right at this point that
 ml> there could be a problem... if there is already a file XYZ in TICHOLD,
 ml> and another file of the same name is processed for forwarding on, does
 ml> the second XYZ file overwrite the first one or what?

You likely have an option in your tic tosser called send original (aka sendorig
in hpt).  This will make htick act exactly like allfix.  Otherwise, it sends
the file directly out of the filebase directory.  The only case one would need
to do this is on systems where the sysop would add a zip banner or addfile to
the zip archive and would not want to pass altered copies to the downlinks.
Otherwise, sending directly from the filebase directory is fine and not only
that, saves space. Though space is not really a concern anymore.  :-)

 ml> i know that allfix works directly with frontdoor's STQ (Static
 ml> Transmission Queue) which does have the ability to store the local
 ml> name and the transmission name... however, none of this type of stuff
 ml> works in a binkley style setup...

And still would solve nothing since the receiving system would have difficulty
in handling the duplicate name in such a short duration.  I believe any
renaming should be done by the receiving system and binkd is capable of doing
this.

 ml> environments... BSO type mailers simply loose out pretty much all
 ml> around because they simply don't have the needed abilities to handle
 ml> intricacies such as this...

I really don't think its a limitation of BSO but rather the handling by the tic
processor.  At the same time, I really don't believe the tic processor should
handle such conditions since the condition never should have happened in such a
short interval.

Matt

em: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

---
 * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)