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в команду, чтобы было ясно, что это не проблема с правами доступа к файлам.

Вы пытались добавить --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 /"

В моей настройке ((источником является 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

Используйте правила в файлах фильтров вместо --exclude. Это позволяет пометить исключения как «сохраняемые», что позволит вам удалять непустые каталоги, которые содержат исключенные файлы.

Видеть этот ответ для деталей.

Каталог должен быть пустым, чтобы вы могли его удалить, обычно это требуется файловой системе.

Поэтому нормально rsync или rmрекурсивно сначала удаляет все содержимое, а затем удаляет пустой каталог.

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

Моим первым предположением будет то, что некоторые файлы в этом каталоге принадлежат другому пользователю, например, apache или nobody.