По-моему, это баг с точки зрения логики работы.

Пропатч и собери свой wget.

сообщи своё ценное мнение аффтарам wget-а

Из-за этого, для разных автоматизированных закачек приходится дополнительные проверки делать.

wget -O <имя файла> <URL>
test "$?" != "0" && echo "achtung!" && rm <имя файла> && exit 1

Одна строчка, проверяет также валидность завершения закачек. Удаляет недокачанные. Не благодари.

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

Не так все просто, если закачка часто обрывается и wget с ключом "-c".

Так что от пары лишних строчек в скрипте руки, чай, не отвалятся.

Если аккуратно делать не пара лишних, но это по-любому усложнение логики работы.

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

Ну, это уже в условия начальной задачи не входило. Как бы там ни было, проверять успешность завершения работы wget - нужно. А там уже внутри условия по обработки ошибки загрузки (не докаченной или даже не начатой) добавить одну строчку на проверку длины файла и его удаления при нулевой длине.

Работать с файлами при автоматизации вообще нужно осторожно. И тестировать всё перед использованием в продакшене. А если руки кривые, то факап - это только вопрос времени.

Это понятно, но просто вопрос что такая логика кажется не только в wget.

Может с философской, так сказать точки зрения, это и вовсе баг архитектуры файловых систем. Если бы файл мог быть не только с данными или нулевой длины, но и имел состояние «неопределено» или «не инициализирован» (undefined). И это третье состояние сигнализировало только о том, что создано имя файла, но в него никогда не записывались данные, которые не известны. А данные нулевой длины - это тоже в некотором роде данные.

проще так

wget -O <имя файла> <URL> || rm <имя файла>

тогда если не докачался, то удалит всё, что успел утянуть

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

Потому что эти идиоты открывают файл на запись до начала закачки. В curl так же.
Из-за этого приходится мутить костыли, чтобы fanotify/inotify не срабатывал на нулевые файлы.

Багрепорт есть?

А как ты хотел? Браузер так же делает + еще и временный файл. Да, браузер потом удаляет нагаженное, но на то он и браузер. А тут просто прилага чтобы качнуть — и делай потом с этим все что хочешь — код ответа тебе дали, файл тебе дали.

Не нужен. Все корректно.

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

См. выше. Все почему-то считают, что «это нормально». Есть обратный «пофикшенный» баг https://github.com/curl/curl/issues/183

Они обосновали свою позицию и добавили свои патчи.

Твоё утверждение с обработкой fanotify тоже имеет смысл. Рекомендую запостить баг с предложением добавить опцию к curl, чтобы не создавать файлы в случае неудачи именно для юзкейса с fanotify/inotify. Таким образом и дефолтное поведение не пострадает, и ты получишь возможность решить свою проблему.

Зачем создаются файлы нулевой длины при ошибках?

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

ЯННП

Может с философской, так сказать точки зрения, это и вовсе баг архитектуры файловых систем. Если бы файл мог быть не только с данными или нулевой длины, но и имел состояние «неопределено» или «не инициализирован» (undefined). И это третье состояние сигнализировало только о том, что создано имя файла, но в него никогда не записывались данные, которые не известны. А данные нулевой длины - это тоже в некотором роде данные.

Зачем нужно какое-то „особое состояние” если данные нулевой длины — это тоже данные?

данные, которые не известны

Из /dev/random чтоль?

А вообще с точки зрения логики работы wget костыльное говно. Например, чтобы нормально с ним работать необходимо указать как минимум две дополнительные опции.

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

даже если открывать в режиме толькочтения?

hint: O_CREAT

Curl возвращает результат работы. Уверен, что и wget тоже возвращает результат. Следовательно никаких лишних проверок делать ненужно.

Нет, просто wget не должен создавать никаких файлов при ошибках.

Это называется консистентное, предсказуемое поведение программы.