Text 41028, 84 rader
Skriven 2006-10-09 20:38:32 av mark lewis (1:3634/12.0)
  Kommentar till text 40889 av Matt Bedynek (1:106/1)
Ärende: FNEWSN39
================
 ml> remote systems with another name... my FD does this quite a bit and
 ml> this is a feature that came with the STQ (static queue) when it was
 ml> introduced... in fact, this is one of the reasons why the STQ was
 ml> implemented ;)

 MB> But the question I have is how do you know changing the send name
 MB> will solve a problem for the receiver?  I just don't see this 
 MB> really being a useful feature.  I would rather someone send me the 
 MB> file name as-is and let me do the renaming. 

ermmm... get the to a DOS or windows box running software that only does 8.3
filenames and then tell me how it will handle something like
max-3.03-etc.tar.gz  ;)

FD can handle that with an 8.3 local filename and transmit the longname as well
as the shortname so that the receiving system can choose whichever fits the
local abilities...

don't forget that much of fidonet is still running old style "DOS-think"
software... if i was forced to change my software, i would do as many others
and just simply pull the plug 'cause it isn't worth it... not like it used to
be...

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

 MB> Unless the STQ keeps a history of recent files sent, renaming the
 MB> file still presents a problem for the reciver unless the filename
 MB> inside the tic is forwarded; thus, still requiring manual
 MB> processing at some stage in the process. 

no manual process at all... somehow we (you and i) are not communicating... i'm
trying to explain how there could/should be a fully automatic method to this so
that shortnames and longnames are both used as needed and that the mailer and
the file processing both communicate between themselves about the situation
if/when it arrives... if the tics don't carry shortname and longname, then
there's no way to do it that i know of... if they do carry both, then it would
take a mailer that could read the tic for that info or some other means of
being informed by the tic processor... in my case, allfix can write directly to
FD's STQ and i hope that it would be able to handle this but i don't know as
i've not tried it... i only know what the FD STQ specs say can be done and
how... i don't know what allfix or any other tic processor does... in the
specific case of allfix and fd, seeing's how harald was on the fd beta team, i
would tend to believe that he did implement this capability...

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

 MB> A binkley problem?  when using htick with bso, it does not use kill
 MB> file sent (kfs).  Instead, htick has a clean directive that will
 MB> purge the file after no more attaches containing the filename
 MB> exist.

right... that's what had to be added to binkley and other derivitives when this
problem was discovered... not a "clean directive" but code had to be added to
scan to see if any other ?LO files needed an attached file before it was
removed...

 MB> However, here, I run a split setup using BSO for mail only
 MB> and filebox for tic.  Though there are some inherit weakness to the
 MB> process, I do not see any method really offering advantages. 

i'm in kinda the same... i run split MSG/Opus-style and fileboxes...

 ml> actually, it is a problem in the tic processors and the mailers... and
 ml> since the two of them don't talk about this, it compounds the
 ml> problem... the tic processors can talk about it because they
 ml> process/read the tic file...

 MB> I suspect though that this late in the game nothing will come of
 MB> this discussion since the major players are no longer actively
 MB> being developed.  :-( 

exactly... but the discussion can open some eyes %)

)\/(ark

 * Origin:  (1:3634/12)