rjek / fling Goto Github PK

Input and output have differing sizes. This could be either a bug in fling or a bug in Microsoft's pipe/splice implementation. Some investigation is warranted, anwyay.
-rw-rw-rw- 1 rjek rjek 1049292800 Dec 8 09:42 fling.in
-rw-rw-rw- 1 rjek rjek 1048096768 Dec 8 09:42 flung.out
Also it is very slow - 27MiB/sec.

I think the -p option results in garbage on screen after a transfer:

18:03 exolobe1:~/.../fling [master]$ ./fling -p exolobe2 8000 < ~/data/v-i/v-i.img 
18:05 exolobe1:~/.../fling [master]$  in 188478.91 seconds, 22.2 kB/sec. 

Note the "in 188478.91 seconds, 22.2 kB/sec." which is left over after the transfer finishes and that the beginning of the line is overwritten by my prompt.

Suggested fix: write out a newline at the end of the transfer before ending the program. This would leave the whole progress report visible.

Also, is the duration correct? 1.9 million seconds seems a lot longer than what I thought it took.

I ran this:

fling -vp exolobe2:sid.img < sid.img

On exolobe2, I get this:

---------- 1 liw liw 4.0G Dec  7 09:01 sid.img

Ideally, the input file's permissions would be copied, but since fling is designed to take input from stdin, including pipes, those aren't always available. For consistency, I suggest the output file is always created with the same permissions, but they should be usable, without being insecure. Can fling set them to 0600?

fling currently tells user that it's using sendfile instead of splice:

            fprintf(stdout, "splicing not possible: %s, trying sendfile\n", strerror(errno));

To me, that looks an awful lot like an error message. Would you accept a PR to change the message to something like:

stdin is a pipe, using splice
stdin is a file, using sendfile

Possibly with additional logic to see whether stdin is a pipe or not.

fling unprivileged@remotehost:/root/foo < bar simply reports "unable to connect" rather than any permission error.

Given we currently leave the redirection of stdout to the receiving end's shell and have no way of reliably parsing any error it produces, we should instead include an option to write to a named file rather than stdout.

A number of warnings are reported on compile

gcc -o fling -O2 -Wall -Wextra -pedantic -std=c99 -lm -lrt fling.c
fling.c: In function ‘spawn_child’:
fling.c:833:13: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  833 |             write(sigpipe[PIPEW], "dup2\n", 5);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fling.c:838:13: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  838 |             write(sigpipe[PIPEW], "dup2\n", 5);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fling.c:843:13: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  843 |             write(sigpipe[PIPEW], "dup2\n", 5);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fling.c:855:9: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  855 |         write(sigpipe[PIPEW], "exec\n", 5);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fling.c: In function ‘read_number_from_file’:
fling.c:254:5: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
  254 |     fscanf(f, "%d", &v);

It'd be great for -p output to say how much is left and long the transfer will still take.

When stdin is from a file, not a pipe, this should be possible.