Утилита gio (бинарник gio поставляется пакетом glib2) при неудаче g_file_move()/g_file_copy() выводит сообщение об ошибке, в котором указание на файл (префикс «gio: <файл>:») всегда относится к исходному файлу, даже если причина отказа — на стороне целевого расположения. По выводу невозможно определить, какое из двух имён в команде является проблемой: например, при перемещении файла в несуществующий каталог ошибка выводится «от имени» исходного файла, который при этом существует, доступен и после неудачной операции остаётся на месте. Недостаток не зависит от типа файлов: в коде CLI выбор исходного файла не связан с тем, какая из сторон операции завершилась ошибкой. Шаги воспроизведения: 1. Создать исходный файл: $ mkdir -p /tmp/a $ touch /tmp/a/src.txt 2. Выполнить перемещение файла в несуществующий каталог: $ gio move /tmp/a/src.txt /tmp/nodir/file.txt 3. Выполнить копирование файла в тот же несуществующий каталог: $ gio copy /tmp/a/src.txt /tmp/nodir/file.txt Фактический результат: gio: file:///tmp/a/src.txt: Ошибка перемещения файла /tmp/a/src.txt: Нет такого файла или каталога gio: file:///tmp/a/src.txt: Ошибка открытия файла «/tmp/nodir/file.txt»: Нет такого файла или каталога В обоих случаях префикс сообщения об ошибке относит ошибку к исходному файлу /tmp/a/src.txt. При перемещении исходный файл назван также и в тексте сообщения, хотя он существует и не изменялся — отсутствует целевой каталог /tmp/nodir. При копировании текст сообщения называет целевой файл, но префикс по-прежнему относит ошибку к исходному. Ожидаемый результат: При ошибке со стороны целевого расположения сообщение об ошибке должно указывать на целевой файл (или не указывать файл вовсе), чтобы по выводу было понятно, какое именно расположение вызвало отказ. Анализ: В инструментах gio при неудаче операции сообщение об ошибке всегда выводится для исходного файла: glib/gio/gio-tool-move.c, handle_move() (метка move_failed): print_file_error (source, error->message); glib/gio/gio-tool-copy.c, handle_copy() (аналогично): print_file_error (source, error->message); print_file_error() (glib/gio/gio-tool.c, строка 50) выводит строку в формате «gio: %s: %s», где %s — g_file_get_uri() переданного (всегда исходного) файла. Код ошибки (G_IO_ERROR_NOT_FOUND) при этом формируется корректно, и причина отказа действительно на стороне целевого расположения: - при перемещении g_file_move() вызывает нативную реализацию g_local_file_move() (glib/gio/glocalfile.c), где g_rename() завершается с ENOENT, т.к. родительский каталог целевого файла не существует; сообщение строится от исходного файла («Error moving file %s: %s», glocalfile.c, строка 2662); - при копировании не удаётся открыть целевой файл (g_open с ENOENT), сообщение строится от целевого файла («Error opening file “%s”: %s», glib/gio/glocalfileoutputstream.c, set_error_from_open_errno(), строка 664) — т.е. текст сообщения корректен, но префикс CLI относит ошибку к исходному файлу. Проверено: p11: glib2 2.84.4-alt1 (gio-tool-move.c, строка 202; gio-tool-copy.c, строка 217; glocalfile.c, строка 2662; glocalfileoutputstream.c, строка 664) — воспроизведение подтверждено на стабильных p11-пакетах, без патчей заданий; sisyphus: glib2 2.90.1-alt1 (gio-tool-move.c, строка 224; gio-tool-copy.c, строка 241; glocalfile.c, строка 2876) — поведение идентично, проверено по исходному коду. Код — исходный upstream (glib 2.84.4 / 2.90.1); локальные ALT-патчи glib2 не вносят изменений в файлы gio-tool-*.c, т.е. поведение не связано с локальными модификациями. Поведение является многолетним upstream-поведением CLI gio.
