I've gotten a few remarks that mail packets I send, all end with the same extention - e.g. .SU0 I asked, and was answered that they did indeed toss mail upon receiving. Is it possible to sequentially number the extentions even if the first packet is already gone? IE - .TU0, and when sent next extention to be TU1. It seems that this is confusing people who see the following stuff in log files.
There is more to that, and this is not the first complaint I had. In retrospect this particular node checked further and found that there really was no problem. I seem to recall though that other tossers do indeed sequentially number the archived packets. Is it a hard thing to do, or does anyone else care about this?
There is more to that, and this is not the first complaint I had. In
retrospect this particular node checked further and found that there
really was no problem. I seem to recall though that other tossers do
indeed sequentially number the archived packets. Is it a hard thing
to do, or does anyone else care about this?
It would require keeping track of the last bundle file sent (these are bundles, not packets). So it'd be a considerable amount of extra book keeping for really no good reason.
There is more to that, and this is not the first complaint I had. In
retrospect this particular node checked further and found that there
really was no problem. I seem to recall though that other tossers do
indeed sequentially number the archived packets. Is it a hard thing to
do, or does anyone else care about this?
It would require keeping track of the last bundle file sent (these are bundles, not packets). So it'd be a considerable amount of extra book keeping for really no good reason.
09 Mar 16 03:15, you wrote to Joe Delahaye:
There is more to that, and this is not the first complaint I had. In
retrospect this particular node checked further and found that there
really was no problem. I seem to recall though that other tossers do
indeed sequentially number the archived packets. Is it a hard thing to
do, or does anyone else care about this?
It would require keeping track of the last bundle file sent (these are bundles, not packets). So it'd be a considerable amount of extra book keeping for really no good reason.
ummm... this is exactly the reason that mailer's have an attribute or setting of "delete after sending" or "truncate after sending"... no extra book keeping needed ;)
clarity: the tosser already has to look and see if there's an existing bundle... if there is, it already has to look at the bundle's file size... if the file size is not zero, the tosser adds the new PKTs to the old bundle as long as it is not being transmitted right now... if the existing bundle's size is zero then it has been transmitted and truncated so the number in the extension is incremented and the tosser carries on like normal by adding the PKTs to the new bundle name... oh yeah, that old truncated zero byte bundle name is deleted by the tosser after it has decided to create a new bundle with a new number...
It would require keeping track of the last bundle file sent (these
are bundles, not packets). So it'd be a considerable amount of extra
book keeping for really no good reason.
ummm... this is exactly the reason that mailer's have an attribute or
setting of "delete after sending" or "truncate after sending"... no
extra book keeping needed ;)
SBBSecho has the same option (set echocfg->Toggle Options->Bundle Attachments to "Truncate") and I suppose it's for that very purpose.
Probably related to this feature, SBBSecho won't delete (or re-use)
0-byte bundle files unless they are > 24 hours old.
complaints like the one that started this topic... i have to wonder if the OP has that setting set to "truncate" or "delete"... if "delete", it would explain
why they are sending the same bundle names all day long... another option they have is to set all their links to "archiver=none" and send raw PKTs... that will surely stop the complaints about the same bundle names
complaints like the one that started this topic... i have to wonder
if the OP has that setting set to "truncate" or "delete"... if
"delete", it would explain why they are sending the same bundle names
all day long... another option they have is to set all their links to
"archiver=none" and send raw PKTs... that will surely stop the
complaints about the same bundle names
I went back after reading this set of messages, and I had it set to 'delete'. That has now been changed.
I went back after reading this set of messages, and I had it set to
'delete'. That has now been changed.
that should take care of your whiner, then ;)
Re: Packet file naming.
By: mark lewis to Joe Delahaye on Wed Mar 16 2016 10:11:54
I went back after reading this set of messages, and I had it set to
'delete'. That has now been changed.
that should take care of your whiner, then ;)
I had two problems, One was not so bad, except it formatted a packet with the same file name for two locations. I suppose the one it was for, never received that mail. The other was for bundles with the same extention.
THat COULD be a problem is one does not immediately import mail and then download a new bundle with the same extention <G>.
I also did as DM
suggested and upgraded to the latest version of SBBSEcho, which was supposed to have fixed one of those problems. (the first one I believe)
I went back after reading this set of messages, and I had it set to
'delete'. That has now been changed.
that should take care of your whiner, then ;)
I had two problems, One was not so bad, except it formatted a packet
with the same file name for two locations. I suppose the one it was
for, never received that mail.
The other was for bundles with the same extention. THat COULD be a
problem is one does not immediately import mail and then download a
new bundle with the same extention <G>.
I also did as DM suggested and upgraded to the latest version of
SBBSEcho, which was supposed to have fixed one of those problems. (the first one I believe)
Mailers are supposed to handle that scenario and either refuse to receive or rename the target file upon receive.
Re: Packet file naming.
By: Digital Man to Joe Delahaye on Wed Mar 16 2016 14:13:54
Mailers are supposed to handle that scenario and either refuse to receive or rename the target file upon receive.
What happened in this case, was that the file was received, processed and found to be not for them, and relegated elsewhere. The second instance WAS for them and was processed properly. Same file name.
Mailers are supposed to handle that scenario and either refuse to
receive or rename the target file upon receive.
What happened in this case, was that the file was received, processed
and found to be not for them, and relegated elsewhere. The second
instance WAS for them and was processed properly. Same file name.
And a different issue.
What happened in this case, was that the file was received,
processed and found to be not for them, and relegated elsewhere. The
second instance WAS for them and was processed properly. Same file
name.
And a different issue.
Yes. With the latest upgrades here, the other issue appears solved. I also changed the configuration to NOT delete 0 byte files.
Yes. With the latest upgrades here, the other issue appears solved.
I also changed the configuration to NOT delete 0 byte files.
actually what you did was switch from using KFS (Kill File Sent) to TFS (Truncate File Sent) ;)
Yes. With the latest upgrades here, the other issue appears solved.
I also changed the configuration to NOT delete 0 byte files.
actually what you did was switch from using KFS (Kill File Sent) to
TFS (Truncate File Sent) ;)
Yes, I know that
actually what you did was switch from using KFS (Kill File Sent) to
TFS (Truncate File Sent) ;)
Yes, I know that
then you understand that your wording was inaccurate? ;) the file is not zero bytes when KFS or TFS are applied to it...
actually what you did was switch from using KFS (Kill File Sent) to
TFS (Truncate File Sent) ;)
Yes, I know that
then you understand that your wording was inaccurate? ;) the file is
not zero bytes when KFS or TFS are applied to it...
Have you looked at the Setup? Truncate is mentioned, but so is 0 byte files
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 01:49:06 |
| Calls: | 510 |
| Messages: | 220569 |