rsync не может удалить ошибки непустого каталога, даже с параметром --force
При запуске этой команды:
$ sudo rsync -r --delete --force --checksum --exclude=uploads /data/prep/* /data/app/
Я получаю следующий вывод:
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source
cannot delete non-empty directory: html/js/ckeditor/_samples
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor
Из чтения man rsync у меня сложилось впечатление, что --force опция скажет rsync удалить эти непустые каталоги, что является желаемым результатом.
Ref:
--force force deletion of dirs even if not empty
Как я могу изменить команду для удаления непустых каталогов?
Я использую rsync версии 3.0.8 в Gentoo Base System выпуск 2.0.3, если это актуально.
Обновление: Добавлено sudo в команду, чтобы понять, что это не проблема с правами доступа к файлам.
5 ответов
Вы пытались добавить --delete-excluded?
Если вы удалите каталог в исключенных папках на "удаленной" стороне, rsync --delete не удалит исключенную папку на вашем "локальном" сайте.
Вот возможные источники этой проблемы:
(1) Эта ошибка может быть результатом опции -b (--backup). Эта опция создаст резервную копию каждого удаленного файла, добавив тильду (~) к имени файла. (Это смутило меня, поскольку имя файла явно является резервной копией, а имя каталога - нет, поскольку вы не можете видеть тильду.)
Чтобы проверить, является ли это тем же случаем, прочитайте ваш целевой каталог на самом глубоком уровне и проверьте, есть ли какой-нибудь конечный файл тильды (~). Обратите внимание, что эти имена-тильды-добавленные-файлы затем невидимы в какой-то распространенной системе просмотра файлов, поэтому вы можете их не видеть.
Чтобы решить этот случай, используйте параметр --backup-dir=DIR, например --backup-dir =.rsync_bak.
(2) Опция --exclude может иметь те же результаты. Что, возможно, происходит в вашем случае. Система шаблонов является мощной, но может вводить в заблуждение. Например, если вы напишите --exclude='*~', это пропустит все конечные файлы тильды, в результате, точно так же, как в случае (1) выше.
со страницы руководства rsync:
если шаблон начинается с /, то он привязывается к определенной точке в иерархии файлов, в противном случае он сопоставляется с концом пути
Если вы напишите --exclude=uploads, это исключит все файлы с именем "updloads" на любом уровне вашего дерева файлов.
Проверьте, есть ли файл с именем "uploads" внутри ваших каталогов, которые невозможно удалить.
Решением было бы изменить "--exclude=uploads" на "--exclude=uploads/"
Используйте правила в файлах фильтров вместо --exclude, Это позволяет пометить исключения как "сохраняемые", что позволит вам удалять непустые каталоги, которые содержат исключенные файлы.
Смотрите этот ответ для деталей.
В моей настройке ((источником является Ubuntu формата ext4 для целевого типа Western Digital fuseblk), он работает с:
rsync -a -v --progress --modify-window=1 -c -b -i -s -m --del -vv --ignore-errors --chmod=ugo=rwx --delete --delete-excluded --exclude='*~' --exclude='.*' --backup-dir=.rsync_bak /home/test /media/user/usbHDD
Каталог должен быть пустым, чтобы вы могли его удалить, обычно это требуется файловой системе.
Поэтому нормально rsync или же rm будет рекурсивно удалять все содержимое сначала и только потом удалять пустой каталог.
Если текущий пользователь не является владельцем всех файлов, разрешения файловых систем не позволят вам удалить эти файлы. Так как они не будут удалены, каталог не очищается, и удаление не удастся.
Моим первым предположением будет то, что некоторые файлы в этом каталоге принадлежат другому пользователю, например, apache или nobody.