| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | polyxarc |
PE> Polyxarc is available on my BBS, comes with C source code, works PE> under MSDOS, OS/2 and AmigaDos, is public domain, and will unarchive PE> mail packets and then (if you want), automatically delete the original PE> archive if it was successful. RS> I think you have missed the point here rather. You MUST check that RS> the unarchiver, whatever it is, has actually unarchived the PKTs RS> successfully without losing any, say because there wasnt enough free RS> space. There is no other viable approach to that bit of the total op. RS> The absolutely LAST thing that should ever be done is to carry on RS> regardless, ignore all error messages, coz that will normally mean RS> that a whole fucking chunk of mail has been silently filed in the RS> bin. If the incoming PKTs have just one big PKT in them, you will RS> likely notice the dearth of mail, but if you have say two reasonably RS> large ones, you may well NOT notice you only got half. PE> Nope. Yep. PE> What you do is have your inbound *.SU0 in one directory, and PE> then do a polyxarc into the other directory. *IF* there was PE> sufficient space to do the decompress to create all the *.PKT, PE> then it will delete the *.SU0. If there's any problem, it leaves PE> the *.SU0 there until you get around to fixing the problem. I can get precisely the same effect with PKUNZIP. So why bother to change to Polyxarc which I dont use for all my other archive stuff and have no idea how bug free it is ? I have extensively tested PKZip when it upgraded to make damned sure it really is doing what its supposed to do and not fucking up. I use it all the time for all my other archive file work and if it had a problem I would have seen it by now. Or more legalistically, if there are remaining problems, they are very subtle ones. I dont have that knowledge about Polyxarc. And that mode of operation doesnt particularly suit me anyway, I dont WANT to delete the archived PKTs. I want to keep them for a bit, atleast until the QWK has been read, so I can rerun the PKT->QWK if there is some fuckup or use the original archive PKTs to apply a new version of PQWK to and see if I get the same QWK produced from it. PE> Which is what I use for my integrity check of getting files PE> from one partition to the other. I can't use "MOVE" to do that. There are other ways around that like a copy/compare/delete op. Not that I bother, I backup thoroughly so if some problem ever arises, the backup is available. And protects me against other problems like the drive dying or the machine getting stolen. --- PQWK202* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 690/718 711/809 934 @PATH: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.