Forum unknown
· Forum Bus/News/HELP
#UnSqueeze et al
9 messages in this thread
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
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.
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
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
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.
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.
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.
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.
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.