Text 40835, 132 rader
Skriven 2006-10-06 04:28:15 av mark lewis (1:3634/12.0)
  Kommentar till text 40824 av Matt Bedynek (1:106/1)
Ärende: FNEWSN39
================
 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...

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

 MB> filearea /var/ftp/pub/fidonews ...

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

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

right... and *there's* where the problem is... the second copy of the file
should _not_ overwrite the original... the tic processor should rename it in
the outbound directory and possibly even adjust the tic file... and that brings
up and next gotcha... how to get the file back to the original name... that
would need to be done by the receiving machine if/when it was told, somehow,
what the original name was... and i do not recall the tic specification having
this ability...

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

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

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

right right right... i already know all this... actually have known it for
numerous years... i lightly touched on "mailer authors dealing with similar" in
another message... guess that hint detector over there is broken since you know
what my preferred mailer is :(  mailers can take a file that has one name on
the local drive and send it to remote systems with another name... my FD does
this quite a bit and this is a feature that came with the STQ (static queue)
when it was introduced... in fact, this is one of the reasons why the STQ was
implemented ;)

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

i disagree when they are sitting on the sending machine together... look what
would have happened if i had gotten the first one and then had my downtime
before processing it... i'd have had the first one with its tic and the second
would have been renamed by my mailer cause there was already one existing in my
inbound... then when my tic processing did happen, the first one would have
been processed properly and the second would have not because of the local name
change from the mailer's renaming it on inbound to prevent the overwrite of the
first one...

 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?

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

i do use send original, yes... my system updates every archive with a zip
comment/banner when it scans and accepts the file...

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

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

not when the file was already overwritten on the sending system before the
connection was made...

the problem is specific to one step in the tic processing... what does the tic
processor do when there is already a file by that name in the outbound
directory? it doesn't matter if that outbound directory is a filebox or not...

FWIW: some BSO mailers had a similar but reverse problem... when using one
outbound directory and sending a file to multiple systems, they would
erroneously erase the file once it had been sent to the first system that they
connected with... that would have been fine if the file was only going to one
system... but it isn't fine when it has to go to more than one... 

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

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

actually, it is a problem in the tic processors and the mailers... and since
the two of them don't talk about this, it compounds the problem... the tic
processors can talk about it because they process/read the tic file... the
mailer doesn't and it only sends the file it is told to send... if the tic
processor were to rename the file so each copy has a unique name and had a slot
in the tic file to specify the file's original name, then this problem would
never happen until processing on the receiving end might happen to overwrite
the file in the filebase (not the outbound)... based on the REPLACES verb and
whether the receiving system allows it...

)\/(ark

 * Origin:  (1:3634/12)