[FR] Support smbd

[Feraidoon Mehri]

I want to see the transfer progress of files via smbd (i.e., file sharing). I already can achieve some results by running progress with sudo:

$ sudo progress -a smbd
[11352] smbd /Users/evar/Base/shared/writable/Docu/Attenborough's Life That Glows (2016).mkv
	0.0% (0 / 336.5 MiB)

But it does not show other files being transferred, which lsof shows:

❯ sudo lsof -p 11352
COMMAND   PID USER   FD   TYPE             DEVICE  SIZE/OFF                NODE NAME
smbd    11352 root  cwd    DIR                1,6      3968          8694568160 /Users/evar/Pictures/wallpapers/bing
smbd    11352 root  twd    DIR                1,6       128          8704772981 /Users/evar/Base/shared/writable
...
smbd    11352 root   21u   REG                1,6          0          8704780221 /Users/evar/Base/shared/writable/Docu/Copy of Japan Earth's Enchanted Islands (2015).mkv

[Feraidoon Mehri]

It also always says everything is at zero, even though the other machine reports slow (~300 KB/s) but steady progress and the completion at 3%.

PS: Is there any other way to measure the transfer speeds of smbd from the mac? iPad doesn't show them, so I need to figure them out from the server (i.e., the mac).

[Julien LOLLIVIER]

progress does not have any specific code path for specific commands, it use the same approach for each process: list opened files and report status on the "biggest" one. Looking at your message, smbd seems threaded and serves multiple files from the same process, and that's no what progress expect (it's more suited to client commands than server multi-threaded daemons)

Also, being able to serve the same file to multiple clients, it's possible that smbd "rewinds" the file after each read. That would explain why progress always shows zero.

I don't see any easy fix for that situation, but I can give a little hope: I want to write a v2 of the tool with a modular approach, so we can write specific code for specific commands, and it looks that Samba would be one of those :)

[Feraidoon Mehri]

@Xfennec Can you add a --report-biggest-n=<number> so that we can ask it to report the biggest N files instead of just one?

To show the speed, we can simply calculate it based on the difference in the filesizes since the last examinations in monitor mode. I.e., we see that a file was at 10MB previously, now after 5 seconds it's at 50MB, so the speed is roughly 40/5=8 MB/s. This, too, can be an option --estimate-speed.

You can even add a --discount-zeroes that calculates the size of the files smartly by skipping the zeroes at the end of the file (used by commands that pre-allocate). I have a rust script to calculate the trailing zeroes, and I imagine it shouldn't be hard in other languages as well:

#!/usr/bin/env scriptisto

// scriptisto-begin
// script_src: src/main.rs
// build_cmd: cargo build --release
// target_bin: ./target/release/script
// files:
//  - path: Cargo.toml
//    content: |
//     package = { name = "script", version = "0.1.0", edition = "2018"}
//     [dependencies]
// scriptisto-end

// https://users.rust-lang.org/t/count-trailing-zero-bytes-of-a-binary-file/42503/4

use std::env;
use std::fs;

fn main() {
    let filename = env::args().nth(1).unwrap();
    let buffer = fs::read(filename).unwrap();
    let count = buffer.iter().rev().take_while(|b| **b == 0).count();
    println!("{}", count);
}

With all these features, progress should support 99% of use cases without any special-purpose code.

[Julien LOLLIVIER]

--report-biggest-n=<number> requires quite some changes, but hey, PRs are welcome ;)

--estimate-speed is the default behavior of progress, no need for a new flag (see my original message for your current issue with smbd)

--discount-zeroes is not very Unix :) (see sparse files)