There already is one: pktsort. It reads all the .pkts in a directory and writes one (or more).
=== Cut ===
FTS-0001 PacketSorter v1.4 [unregistered] (c) 1993, 1994 by Rolf K. Wilms
libg++ (c) 1987-1993 Free Software Foundation (see license.doc)
I have found several ARCMAIL bundles in my INSECURE inbound. They
contain NETMAIL messages from your point 2:333/808.7.
Please make sure NETMAIL is NOT packed into Zipped ARCMAIL, if you
send them CRASH.
* Originally in netmail * Crossposted in points Hi August, I haveHi tommi what date are the netmail? So I do a check ...
found several ARCMAIL bundles in my INSECURE inbound. They contain NETMAIL messages from your point 2:333/808.7. Please make sure
NETMAIL is NOT packed into Zipped ARCMAIL, if you send them CRASH.
Hello, Tommi Koivula.
On 22/03/20 10:24 you wrote:
* Originally in netmail * Crossposted in points Hi August, I have
found several ARCMAIL bundles in my INSECURE inbound. They contain
NETMAIL messages from your point 2:333/808.7. Please make sure
NETMAIL is NOT packed into Zipped ARCMAIL, if you send them CRASH.
Hi tommi what date are the netmail? So I do a check ...
I'm sysop of veleno bbs
I have found several ARCMAIL bundles in my INSECURE inbound. They
contain NETMAIL messages from your point 2:333/808.7.
Please make sure NETMAIL is NOT packed into Zipped ARCMAIL, if you
send them CRASH.
Sounds like a job for.. Superman, er.. DaBoss :)
Those came direct from the point in one session, not from you. ===They are old tests that had been done ... Don't take them into consideration.
Cut === - 04 Mar 21:32:25 [35307] SYS Points Of Veleno BBS - 04
Mar 21:32:25 [35307] ZYZ The BoSS - 04 Mar 21:32:25 [35307] LOC
Italy - 04 Mar 21:32:25 [35307] NDL MO,IBN - 04 Mar 21:32:25
[35307] TIME Wed, 4 Mar 2020 20:32:24 +0100 - 04 Mar 21:32:25
[35307] VER binkd/1.1a-99/Win32 binkp/1.1 + 04 Mar 21:32:25
[35307] addr: 2:333/808.7@fidonet - 04 Mar 21:32:25 [35307] OPT
NDA EXTCMD CRYPT GZ BZ2 + 04 Mar 21:32:25 [35307] Remote supports asymmetric ND mode + 04 Mar 21:32:25 [35307] Remote supports
EXTCMD mode + 04 Mar 21:32:25 [35307] Remote requests CRYPT mode +
04 Mar 21:32:25 [35307] Remote supports GZ mode + 04 Mar 21:32:25
[35307] Remote supports BZ2 mode - 04 Mar 21:32:25 [35307] TRF 0
7556 + 04 Mar 21:32:25 [35307] Remote has 0b of mail and 7556b of
files for us - 04 Mar 21:32:25 [35307] receiving 007001c0.th0 (370 byte(s), off 0) + 04 Mar 21:32:25 [35307] 007001c0.th0 -> \husky\inbound\007001c0.th0 + 04 Mar 21:32:25 [35307] rcvd:
007001c0.th0 (370, 370.00 CPS, 2:333/808.7@fidonet) - 04 Mar
21:32:25 [35307] receiving 00700327.tu0 (358 byte(s), off 0) + 04
Mar 21:32:25 [35307] 00700327.tu0 -> \husky\inbound\00700327.tu0 +
04 Mar 21:32:25 [35307] rcvd: 00700327.tu0 (358, 358.00 CPS, 2:333/808.7@fidonet) - 04 Mar 21:32:25 [35307] receiving
00700327.su0 (1746 byte(s), off 0) + 04 Mar 21:32:25 [35307]
00700327.su0 -> \husky\inbound\00700327.su0 + 04 Mar 21:32:25
[35307] rcvd: 00700327.su0 (1746, 1746.00 CPS,
2:333/808.7@fidonet) - 04 Mar 21:32:25 [35307] receiving
00700327.th0 (767 byte(s), off 0) + 04 Mar 21:32:25 [35307]
00700327.th0 -> \husky\inbound\00700327.th0 + 04 Mar 21:32:25
[35307] rcvd: 00700327.th0 (767, 767.00 CPS, 2:333/808.7@fidonet)
- 04 Mar 21:32:25 [35307] receiving WELCOME.TXT (3590 byte(s), off
0) + 04 Mar 21:32:25 [35307] WELCOME.TXT ->
\husky\inbound\welcome.txt + 04 Mar 21:32:25 [35307] rcvd:
WELCOME.TXT (3590, 3590.00 CPS, 2:333/808.7@fidonet) - 04 Mar
21:32:25 [35307] receiving 00700327.su1 (357 byte(s), off 0) + 04
Mar 21:32:25 [35307] 00700327.su1 -> \husky\inbound\00700327.su1 +
04 Mar 21:32:25 [35307] rcvd: 00700327.su1 (357, 357.00 CPS, 2:333/808.7@fidonet) - 04 Mar 21:32:25 [35307] receiving
00700327.tu1 (368 byte(s), off 0) + 04 Mar 21:32:25 [35307]
00700327.tu1 -> \husky\inbound\00700327.tu1 + 04 Mar 21:32:25
[35307] rcvd: 00700327.tu1 (368, 368.00 CPS, 2:333/808.7@fidonet)
+ 04 Mar 21:32:25 [35307] done (from 2:333/808.7@fidonet, OK, S/R:
0/7 (0/7556 bytes))
04 Mar 21:32:27 [35307] Creating \semapho\toss.now
04 Mar 21:32:27 [35307] session closed, quitting...
04 Mar 21:32:27 [115] rc(35307)=0
=== Cut ===
Hi August. 22 Mar 20 20:59:30, you wrote to me:Hi no I am the sysop of your point because it uses the Veleno bbs web Point system. However as my previous message they were old tests.
I have found several ARCMAIL bundles in my INSECURE inbound.
They contain NETMAIL messages from your point 2:333/808.7.
Please make sure NETMAIL is NOT packed into Zipped ARCMAIL, if
you send them CRASH.
Sounds like a job for.. Superman, er.. DaBoss :)It's your job as the sysop of your point.
Sounds like a job for.. Superman, er.. DaBoss :)
It's your job as the sysop of your point.
Please make sure NETMAIL is NOT packed into Zipped ARCMAIL, if you
send them CRASH.
They are old tests that had been done... Don't take them into
consideration.
The issue here is that the above (primarily crash or routed) wereFor policy netmail do not go directly to the recipient but first pass through my hub and then sort. The netmail of 04 March that you see refers to when the system wanted to send them directly but it failed and therefore now they pass first from my hub and then follow the normal procedure.
sent archived. Meanwhile, regular netmail (routed) is working fine
now. But CRASH/DIRECT netmail seems to be getting archived.
--
Quoted with Reformator/Quoter. Info = https://tinyurl.com/sxnhuxc
Let me know if they are now delivered correctly.
Tommi is trying to tell you that direct mail should not be archived.
Tommi is trying to tell you that direct mail should not be archived.
this day in time, no FTN mailer needs to be bundled... there aren't the speed or size limits there used to be and transmissions take seconds instead of minutes...
minutes...Tommi is trying to tell you that direct mail should not be archived.
this day in time, no FTN mailer needs to be bundled... there aren't the speed or size limits there used to be and transmissions take seconds instead of
I still find arcmail bundles are neat, tidy and efficient.
Tommi is trying to tell you that direct mail should not be archived.
this day in time, no FTN mailer needs to be bundled... there aren't the speed
or size limits there used to be and transmissions take seconds instead of
minutes...
I still find arcmail bundles are neat, tidy and efficient.
diagnostics orI still find arcmail bundles are neat, tidy and efficient.
they're also a PITA when it comes to archiving pkts for possible
recovery... not to mention wasting time just to bundle one pkt as is seenin
so many transfers these days with virtually realtime conversations ;)
I still find arcmail bundles are neat, tidy and efficient.
Correct. :) But arcmail should only be sent via secure link.
And since this is a POINTS echo, it is a good practise to archive thousands of
tiny .pkts instead of sending them separately. Points can't receive crash, normally.
Arcmail doesn't necessarily mean compressing. :)
And August, you have 254 files on hold for your point .59. Would it be time to
pick them up?
=== Cut ===
^\xenia\outbound\00dd0001.pnt\797ac504.pkt ^\xenia\outbound\00dd0001.pnt\79468f08.pkt ^\xenia\outbound\00dd0001.pnt\79437604.pkt ^\xenia\outbound\00dd0001.pnt\7926b005.pkt
I still find arcmail bundles are neat, tidy and efficient.
Correct. :) But arcmail should only be sent via secure link.
Why is that?
forArcmail doesn't necessarily mean compressing. :)
When I think of arcmail I think of a bundle of PKT files archived together
easy storage and delivery to the recipient. Is there more to it?
toAnd August, you have 254 files on hold for your point .59. Would it be time
pick them up?
=== Cut ===
^\xenia\outbound\00dd0001.pnt\797ac504.pkt
^\xenia\outbound\00dd0001.pnt\79468f08.pkt
^\xenia\outbound\00dd0001.pnt\79437604.pkt
^\xenia\outbound\00dd0001.pnt\7926b005.pkt
Whowah! That's what I'm talkin' about!
Correct. :) But arcmail should only be sent via secure link.
Why is that?
Many tossers, like HPT, won't unpack arcmail from insecure inbound.
I don't know if it is possible to tell HPT to do so, but I prefer
not to unpack arcmail from untrusted sources.
insecureWhy is that?
Many tossers, like HPT, won't unpack arcmail from insecure inbound.
I don't know if it is possible to tell HPT to do so, but I prefer
not to unpack arcmail from untrusted sources.
that seems like a flaw in their design... unpacking bundles in the
inbound should not be a problem...
I still find arcmail bundles are neat, tidy and efficient.
they're also a PITA when it comes to archiving pkts for possible diagnostics or recovery... not to mention wasting time just to bundle
one pkt as is seen in so many transfers these days with virtually
realtime conversations ;)
And since this is a POINTS echo, it is a good practise to archive thousands of tiny .pkts instead of sending them separately. Points
can't receive crash, normally.
Arcmail doesn't necessarily mean compressing. :)
And August, you have 254 files on hold for your point .59. Would it be time to pick them up?
Should I turn on arcmail? :)
filesI still find arcmail bundles are neat, tidy and efficient.
they're also a PITA when it comes to archiving pkts for possible
diagnostics or recovery... not to mention wasting time just to bundle
one pkt as is seen in so many transfers these days with virtually
realtime conversations ;)
Maybe this is a good time to have a utility that merges individual .pkt
into a big one, say if the pkts qty reaches a certain number.
Arc or no arc makes no real difference me, but recall a certain boss
node operator tell me that disk space is no problem these days. ;)
..a certain boss node operator tell me that disk space is
no problem these days.
not only that but directories can hold a lot more individual
files these days than back in the DOS FAT-16 and FAT-32 days..
specifically, DOS used to see a huge slowdown if there were
over 255 files in one directory...
Maybe this is a good time to have a utility that merges individual
.pkt files into a big one, say if the pkts qty reaches a certain
number
there are already one or two tools that do this...
i used to use a similar tool here for other reasons but quickly
dropped/disabled the sorting and pkt combining functions...
files into aI still find arcmail bundles are neat, tidy and efficient.
they're also a PITA when it comes to archiving pkts for possible
diagnostics or recovery... not to mention wasting time just to bundle
one pkt as is seen in so many transfers these days with virtually
realtime conversations ;)
Maybe this is a good time to have a utility that merges individual .pkt
big one, say if the pkts qty reaches a certain number.
experimentation.And August, you have 254 files on hold for your point .59. Would it be
time to pick them up?
Sorry. Thanks for the reminder. I was distracted with my QWK
Should I turn on arcmail? :)
I dunno. Can you merge the pkts into a mega pkt? LOL
AA>> ..a certain boss node operator tell me that disk space is
AA>> no problem these days.
ml>not only that but directories can hold a lot more individual
ml>files these days than back in the DOS FAT-16 and FAT-32 days..
ml>specifically, DOS used to see a huge slowdown if there were
ml>over 255 files in one directory...
Does the same limitation still apply when virtualizing 16-bt OSes, or operating a BBS with DOSbox?
I sincerely *do* apologize for neglecting to poll for several long
weeks with my other point account.
operating a BBS with DOSbox?..a certain boss node operator tell me that disk space is
no problem these days.
not only that but directories can hold a lot more individual
files these days than back in the DOS FAT-16 and FAT-32 days..
specifically, DOS used to see a huge slowdown if there were
over 255 files in one directory...
Does the same limitation still apply when virtualizing 16-bt OSes, or
i used to use a similar tool here for other reasons but quickly
dropped/disabled the sorting and pkt combining functions...
I have hunted for it/them, but have not found anything.
Do you remember a filename, key words or description?
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 66 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 15:47:43 |
| Calls: | 718 |
| Files: | 7,654 |
| Messages: | 293,894 |