haavee
commented
3 years ago Fair points! I think these can be addressed moderately easy indeed. The one snag I can immediately think of is that some of the code (specifically the bit that does the actual transfer and does the byte+time keeping) is unaware of whether it is running in the daemon or the client. The unexpected side-effect could be that your client terminal output would be spammed with the same messages as you'd rather see go to the daemon log.
This was by design to have identical code for client->server and server->server transfers i.e. minimize implementation complexity and maintaining different code paths for what should (could) be literally the same process - i.e. moving X bytes from A to B ... ;-)
varenius
etd logs to syslog. With default message level, no information is written about ongoing transfers. It is very useful to be able to see what file is being transferred. This serves to see if the correct files are being transferred and what the progress is of an ongoing transfer of many files. I thought that "filename" would be the first thing logged if giving etd the "-m 1" flag, but that's not the case. It seems one has to go all the way to "-m 4" to get the filename in syslog. Then, I also get a LOT more information which is not of interest. I'd suggest including the filename, e.g. the line Jun 16 09:47:41 skirner etd[10755]: 2021-06-16 07:47:41.01: ETDServerWrapper::handle()/got line: 'read-file 0 /mnt/vbsmnt/b21096_ow_096-1929_3' in the first log level (1) and all the ones above it. Operationally, this is (I think) the most fundamental bit of information, after the fact that etd has started.
If possible, it would also be very good to get the final transfer speed in the logfile after a transfer has finished. It is very useful to be able to monitor files and speeds from the server side too.