Я надеюсь, что более опытный набор глаз найдет что-то очевидное, что я пропал без вести или смогу помочь мне обойти ошибки, которые mv и rsync. Для решения проблемы?Команда mv перемещает файл, но сообщает об ошибке: не может ставить такой файл или каталог
Основная идея:
У меня есть Баш скрипт, в котором я автоматизирующий движение файлов из одного каталога в другой.
Проблема:
Когда я запускаю скрипт, периодически я получаю следующее сообщение об ошибке из команды mv:
mv: cannot stat `/shares/directory with spaces/test file.txt': No such file or directory. Код ошибки из команды vm равен 1. Еще более странно, перемещение файла на самом деле происходит успешно.
Кроме того, у меня есть ветвь логики в скрипте, которая будет поочередно использовать rsync для перемещения/копирования определенных файлов (из того же источника и места локальной файловой системы, что и команда mv, упомянутая выше). Я получаю аналогичную ошибку, связанную со системным вызовом stat():
rsync: link_stat "/shares/directory with spaces/test file.txt" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9]
Эта ошибка не всегда проявляется при запуске скрипта. Иногда он завершает работу файла без жалобы, в то время как в других случаях он будет возвращать ошибку последовательно, когда скрипт запускается подряд.
Существует один дополнительный ингредиент, о котором вы должны знать (и я рос подозреваю, что это ключевой компонент моего горя): каталог/share/- это каталог, который контролируется установкой Dropbox - это означает, что он просматривается и зеркалируется установкой Dropbox. На этом этапе я не могу определить, как dropboxd каким-то образом блокирует файл или что-то подобное, чтобы его нельзя было установить. Чтобы быть ясным, файлы в конечном итоге освобождаются от этого состояния без дополнительного вмешательства и являются mv -able.
Код:
mv -v --no-clobber "${SOURCEPATH}${item}" "${DESTINATIONPATH}${item}"
Подробнее:
Следующая может, или не может, быть уместным:
mountуказывает на то, файловая система ext4- Предположительно , права собственности и разрешения не должен будет проблемой, поскольку скрипт запускается root. Особенно, если файловая система не основана на плавких предохранителях.
- Базовый «каталог» в пути (например,/share /) является символической ссылкой на другой каталог в той же файловой системе.
- Вкус Linux - это Debian.
Устранение:
В попытке устранить любые проблемы с переменным расширением или их содержимое, я попробовал Электромонтаж сценарий Баш, как например:
mv -v --no-clobber "/shares/directory with spaces/test file.txt" "/new destination/directory with spaces/test file.txt" после проверки через ls -al, что «тест file.txt» существует ,Для справки были разрешены следующие разрешения: -rw-r-r--
К сожалению, это также приводит к той же ошибке.
Другие возможные вопросы, которые я мог думать и то, что я сделал, чтобы попытаться исключить их:
>> Возможные проблемы: медленный жесткий диск (или привод находится в режиме малой мощности) или внешний USB накопитель
>> выводы: Приводы - это все локальные диски SATA, которые не имеют парковки.Кроме того, даже при выгонке последовательного чтения из файловой системы, то же происходит ошибка
>> возможный вопрос: не-Linux, NFS или предохранитель на основе файловой системы
>> выводы: Неа, источника и назначения находятся на одной и той же локальной файловой системе и mount указывает файловая система ext4
>> Возможные проблемы: белое пространство или другие непечатные символы в пути к файлу
>> результаты: подтвердили, что пути источника и назначения, где должным образом, завернутые в кавычки
>> возможно вопрос: вопросы продолжения после экранированного перевода строки (пробел после \ в обернутой команды)
>> выводы: убедились, что команда все на одном линия, все та же ошибка
>> возможно вопрос: подстановка (использование * при определении файлов для перемещения)
>> результаты: Нету, каждый файл задается непосредственно путь и имя
>> возможно вопрос: путь путаницы с использованием локального пути
>> выводы: Неа, пути к файлам полностью квалифицирован, начиная с/
>> возможный вопрос: файлы на самом деле в пути не указано
>> выводы: Неа, проверить файл существует прямо перед выполнением скрипта через ls -al
>> возможно вопрос: как-то --no-тряпки из мв причинял вопросы
>> Результаты: Нету, пробовал без, ту же ошибку
>> возможно вопрос: только файлы, созданные с помощью Dropbox синхронизации к файловой системе являются проблематичными
>> результаты: Нету, создал локальный файл непосредственно через touch new-local-file.txt и он тоже произвел ошибку же стат()
Мой анализ:
Того факт, что mv и rsync произвести аналогичный стат() ошибка приводит меня к мысли:
- есть некоторый системный основной пограничный случай (например, права доступа к файлам/право собственности или файл заняты), которые не учитываются в сценарии bash; или
- такая же ошибка преследует меня как в
mv, так и в сценахrsync.
Желаемые результаты:
1. Основной причиной прерывистых ошибок могут быть идентифицированы.
2. Основная причина может быть решена или проработана.
3. Сценарий bash можно улучшить, чтобы грациозно обрабатывать при возникновении ошибки.
Дополнительная информация: Я отредактировал скрипт bash для запуска '/ usr/bin/stat' в файле, когда' mv' привел код выхода> 0. Я открыл 2 оболочки: в одном я побежал 'while true; найти. -exec stat {} \ ;; done'. Я скопировал файл в исходный путь и увидел, что он отображается в цикле «stat» просто отлично. В другой оболочке я запустил скрипт bash. 'mv' и' stat' бросили ошибки 'не могут stat ... нет такого файла'. Несмотря на ошибку из «mv», файл был фактически перемещен. Это объясняет, почему 'stat' выдал ошибку, но не объясняет, почему' mv' сделал. Успешное перемещение файла также проверялось с помощью выхода цикла «stat». –