dumbpipe doesn't seem to signal when the pipe operation has "ended"

[AccessViolation95]

I'm using dumbpipe to cat a file over a network connection and receive it on the computer that's connected to a tape drive (/dev/nst0), to write the file to tape.

When the cat file | dumbpipe connect [ticket] side is done, it doesn't seem to signal that to the dumbpipe listen | mbuffer -o /dev/nst0 on the other machine, so I need to do these steps in this order:

• press Ctrl+c on the sending end.
• press Enter on the receiving end (which seems cause some 'closing' action on either mbuffer or dumbpipe).

If I instead Ctrl+c out on the receiving end, it seems mbuffer doesn't flush the final bit of data, which results in the last 40 or so kilobytes never being written to tape.

[eminence]

Does using --recv-only option on the "listening" side help? This will tell the listening side (which appears to only pipe to mbuffer) that it will never be sending data back to the "connect" side?

This sounds like #10

[AccessViolation95]

quite the contrary, --recv-only seems to always result in a premature end of the stream.

I've also verified that the issue is not to do with mbuffer. I can pipe it into wc -c to see the count of transmitted bytes or zstd --test (the files are Zstandard compressed) or b3sum to take the hash, and the same problem arises with all

[eminence]

That's surprising to me. Just to confirm, you added --recv-only to only the receiving side, and not the sending side?

[AccessViolation95]

that's right. when I add it to the receiving side, the sending side indeed exits out when it's (supposedly) done, and at that point, my method of pressing enter on the receiving end, and even just letting it set after which it automatically finishes after a little while, no longer works. it results in data missing regardless

[eminence]

Note: when using --recv-only, you should not have to press anything on your keyboard on either side: Both sides should cleanly exist when all of the data has been sent.

Some questions to help better categorize the problem:

Can you reproduce this for any arbitrary input on the sender side?

Does the size of the input seem to matter in terms of how often this issue reproduces? Or does it always reproduce?

You said above that sometimes the last 40kB seem to go missing. When do you do have missing data, is it always at the end? Is the missing data always about the same size?