public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Bug with chunked files
@ 2023-04-28 16:42 AsmodeusB
2023-04-29 11:07 ` Sergey Matveev
0 siblings, 1 reply; 3+ messages in thread
From: AsmodeusB @ 2023-04-28 16:42 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
It looks like there is a bug with chunked files where the file size is an
integer multiple of the chunk size.
Version: 8.8.2 built with go1.19.3
(debian-backports 8.8.2-2~bpo11+1 linux amd64)
To replicate:
- Create a file that is exactly 1MB, for example (1048576 bytes)
dd if=/dev/random bs=1M count=1 of=1m
- nncp-file to send it, -chunked 512 (or 256, 128, 64, 32, 16, 8, 4, 2, 1)
(I was using nncp-xfer to transfer)
- nncp-toss to get the .chunk and .meta files on the destination node in
incoming/
- nncp-reass the file to hit the error:
ERROR Reassembling chunked file "/var/spool/incoming/1m.nncp.meta": chunk
1: invalid size
(this was using 512k chunks; it's always the last chunk it complains about)
If the chunks are concatenated together, the original file is recovered, so
the issue appears to be with nncp-reass, not creation or transmission.
If the file is instead one byte smaller (1048575 bytes), it reassembles
without error; same with one byte larger.
The problem isn't related to a power of 2. For example, a 6KB file (6144
bytes) -chunked 3, 2, or 1 will hit the same error.
[-- Attachment #2: Type: text/html, Size: 1440 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug with chunked files
2023-04-28 16:42 Bug with chunked files AsmodeusB
@ 2023-04-29 11:07 ` Sergey Matveev
2023-05-01 17:16 ` AsmodeusB
0 siblings, 1 reply; 3+ messages in thread
From: Sergey Matveev @ 2023-04-29 11:07 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Greetings!
*** AsmodeusB [2023-04-28 12:42]:
>It looks like there is a bug with chunked files where the file size is an
>integer multiple of the chunk size.
Thanks for the report! Indeed there was a bug in nncp-reass logic for
the last chunk:
badSize = uint64(fi.Size()) != metaPkt.FileSize%metaPkt.ChunkSize
Fixed in 8.8.3 release.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Bug with chunked files
2023-04-29 11:07 ` Sergey Matveev
@ 2023-05-01 17:16 ` AsmodeusB
0 siblings, 0 replies; 3+ messages in thread
From: AsmodeusB @ 2023-05-01 17:16 UTC (permalink / raw)
To: nncp-devel
> Thanks for the report! Indeed there was a bug in nncp-reass logic for
> the last chunk:
> badSize = uint64(fi.Size()) != metaPkt.FileSize%metaPkt.ChunkSize
>
> Fixed in 8.8.3 release.
Great! Thank you for the quick fix, Sergey!
And also for creating this software. Not having any UUCP background,
some things seem a bit counter-intuitive, but it looks like it has
great potential for essentially adding delay tolerance to an existing
process, which would be handy with my interests leaning more towards
intermittent and slow connectivity.
It's funny--when I used to run a USENET server, I remember looking at
the INN documentation and wondering why on earth people would want to
use a UUCP feed rather than NNTP, but I'm older and can see cases
where always-on, always-working connectivity can't/shouldn't be
assumed, even though the always-on part is often true.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-05-01 17:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-28 16:42 Bug with chunked files AsmodeusB
2023-04-29 11:07 ` Sergey Matveev
2023-05-01 17:16 ` AsmodeusB