CompuServe Thread

Forum unknown · Forum Bus/News/HELP

#UnSqueeze et al

9 messages in this thread
#10138From: Bela Lubkin/SysopMar 2, 1986 8:46 PM
Jeff, when the DL software displays the file size of a binary file, it >never< gets it right. It always adds some amount (not a percentage, not a fixed amount… I'm not sure >what< it's doing). This is a long standing bug. I've asked CIS to fix it, and gotten no response. Maybe some requests through FEEDBACK would help? When USQ unsqueezes a file, you go from having one squeezed file to having a squeezed file AND a larger, unsqueezed file. USQ probably ran out of space during the unsqueeze, so it deleted the worthless partially unsqueezed file and aborted. That's why you still have lots of free space after it aborts. – Bela
#10154From: Joe MillerMar 2, 1986 11:09 PM
Bela, That's not a bug… The number in parens _does_ represent the actual number of bytes transmitted during the <binary> download. It doesn't represent the resulting file size because (for the A and B protocols) all characters less than $20 are actually sent as the two byte pair: DLE ($10) followed by (char .or. $40). So, even if the file was uploaded with XMODEM (which doesn't use this "transparency" character), the binary file size is shown this way. It will always show the actual file size _plus_ the number of control characters in the file.
#10174From: Bela Lubkin/SysopMar 3, 1986 1:54 AM
That doesn't make it any less a bug! Which number is more useful, the actual size of the file, or the number of characters that will be sent by some (SOME) of the protocols that might be used to download it? I see questions about file sizes all the time ("The DL listing says that XYZ.EXE is 12345 bytes long, but it was only 12000 bytes when I downloaded it. What's wrong?"). If it gave the true file size, how often do you think you'd see "I downloaded XYZ.EXE, and I watched my modem lights and saw that it sent 12345 bytes, but the DL listing says it's 12000 bytes long"? The number can't be right for binary downloads anyway, because each of the three binary protocols will have a different number of overhead characters (handshaking, etc.), plus there's the possibility of transmission glitches resulting in retries. I'm forwarding this thread to CIS management… – Bela
#10174From: Bela Lubkin/SysopMar 3, 1986 1:54 AM
That doesn't make it any less a bug! Which number is more useful, the actual size of the file, or the number of characters that will be sent by some (SOME) of the protocols that might be used to download it? I see questions about file sizes all the time ("The DL listing says that XYZ.EXE is 12345 bytes long, but it was only 12000 bytes when I downloaded it. What's wrong?"). If it gave the true file size, how often do you think you'd see "I downloaded XYZ.EXE, and I watched my modem lights and saw that it sent 12345 bytes, but the DL listing says it's 12000 bytes long"? The number can't be right for binary downloads anyway, because each of the three binary protocols will have a different number of overhead characters (handshaking, etc.), plus there's the possibility of transmission glitches resulting in retries. I'm forwarding this thread to CIS management… – Bela
#10178From: Bela Lubkin/SysopMar 3, 1986 2:42 AM
Wrong. I just checked: I uploaded three files, each 4096 bytes in length. The first was all control characters, the second was mostly test ("this do be a test" CR LF repeated for 4K's worth), the third was entirely text (leave out the CRLFs). All three came out the same size in the DL directory (which I forgot to note… 4480?) – Bela PS: plus I downloaded an existing file and checked its size+the number of control characters in it against the DL's listed size. The DL listing would have added even more than it did if you were right.
#10217From: Joe MillerMar 3, 1986 12:28 PM
I stand corrected then. I was given this explanation by a Sysop on another SIG who has also just released a "major" telecommunications pgm supporting CIS 'B' and had spent some time looking into it. When _you_ find out what the (xxx) number really means, please pass it along.
#10217From: Joe MillerMar 3, 1986 12:28 PM
I stand corrected then. I was given this explanation by a Sysop on another SIG who has also just released a "major" telecommunications pgm supporting CIS 'B' and had spent some time looking into it. When _you_ find out what the (xxx) number really means, please pass it along.
#10178From: Bela Lubkin/SysopMar 3, 1986 2:42 AM
Wrong. I just checked: I uploaded three files, each 4096 bytes in length. The first was all control characters, the second was mostly test ("this do be a test" CR LF repeated for 4K's worth), the third was entirely text (leave out the CRLFs). All three came out the same size in the DL directory (which I forgot to note… 4480?) – Bela PS: plus I downloaded an existing file and checked its size+the number of control characters in it against the DL's listed size. The DL listing would have added even more than it did if you were right.
#10154From: Joe MillerMar 2, 1986 11:09 PM
Bela, That's not a bug… The number in parens _does_ represent the actual number of bytes transmitted during the <binary> download. It doesn't represent the resulting file size because (for the A and B protocols) all characters less than $20 are actually sent as the two byte pair: DLE ($10) followed by (char .or. $40). So, even if the file was uploaded with XMODEM (which doesn't use this "transparency" character), the binary file size is shown this way. It will always show the actual file size _plus_ the number of control characters in the file.