dd api?

Никаких API для dd не существует. Просто суй его в shell script и работай с dd уже там.

шоб я ещё хоть раз с этим связался.

Что так категорично? Какие-то трудности?

Разве dd делает что-то сложнее чем прочитать N байт из «файла» А, записать их в «файл» В, повторить? Зачем тебе API к этому?

Запустил, а дальше что? Как управлять этим? Как прогресс отслеживать? Как жить, если у юзера китайский язык или версия другая, в которой выхлоп отличается?

Выхлоп

stdout stderr

Управлять

ключи в переменных

Язык

локали

Если шлёпаешь гуйню — то тебе нужно искать интерфейс работы с шеллом(или просто открывать окно терминала 😁).

stdout

шоб я ещё раз связался™ с парсингом человекочитаемого

ключи

они разные, не везде, например, status=progress есть.

локали

Как бы да, но да. Этого я и хочу избежать - вместо перекладывания байтиков придётся думать о локалях, версиях, парсить что-то, и успех операции будет известен уже в рантайме, никаких гарантий относительно совместимости, которые могли бы дать пакетный менеджер и хидеры софтины.

мя не настолько глупый <_<

нет особой проблемы запустить процесс, потяпать его ввод/вывод и кильнуть при необходимости, но это вещь в себе с очень ограниченными возможностями взаимодействия.

Зачем тебе API к этому?

Захотелось!

они разные, не везде, например, status=progress есть

Ты UNIX-agnostic софт делаешь? Тогда делай в соответствии с POSIX.

Не, я серьезно. Бери да копируй сам. Read, write, repeat. Перед повтором можешь проверить условие выхода из цикла.

мя не настолько глупый <_<

Извини, просто я - настолько 😄. Помогаю в силу своих небогатых познаний. Ну, наверное, мне больше сказать и нечего.

Понимаю, что можно втупую перекладывать байты из файла в файл

Это вобщем-то единственный способ. И лучше делать чтение/запись большими блоками, например по 1048576 байт (выравнивая позицию до этих границ). dd это интерфейс командной строки к этому действию.

https://unix.stackexchange.com/questions/12532/dd-vs-cat-is-dd-still-relevant...

лучше

Вот примерно о таких мелочах, возможно, спрятанных под капотом тривиальных утилит, догадываться не очень хочется.

Кринжово-забавная статья на тему: https://habr.com/ru/post/301924/

И тем не менее нужно. Иначе твой софт станет помойкой со временем.

Лично я бы, наверное, написал бы свой класс и засунул его в отдельный поток с настраиваемой возможностью отсылки прогресса вызывающему. Никакого rocket science я тут не вижу, выделил буфер и копируй. Ну вот про оптимальный размер этого буфера можно порассуждать, если предполагается гигабайтные данные копировать…

Как прогресс отслеживать?

lsof -o

dd на какой-то сигнал отвечает, выводя текущий прогресс.

https://github.com/coreutils/coreutils/blob/master/src/dd.c

Код dd - 2570 строк, правда инклудов много.

Может быть дешевле прочитать и скоммуниздить \ адаптировать?

Докиньте золота, что значит «клонировать диски из своего софта» ? А то потом всплывут нюансы...

По хорошему надо еще в несколько потоков читать/писать, если речь идет не о hdd, а о nvme, т.к. в один поток максимальной скорости работы не добиться. Для этого было бы рационально заюзать какой нибудь async io api. Тоже не ракетная наука, но подумать есть над чем