Ожидайте каталога перемещения, который будет завершен прежде, чем попытаться удалить его
Лучшее решение состояло бы в том, чтобы создать Ваш пакет с корректными зависимостями. Как быстрый взлом можно отметить пакет, как вручную установлено, это предотвратит autoremove от удаления его.
apt-mark manual python-socksipy
Вы столкнулись flock команда?
Это предоставляет Вам, блокировка файла в файловой системе так может использоваться в сценариях оболочки.
---редактирование
После моего первоначального ответа выше, дальнейшие редактирования были сделаны к исходному сообщению, к которому я добавил комментарии и заключительное предложение состояния состязания через несколько машин, которые используют nfs и разработали сценарий. Этому сценарию бросил вызов @alexis, к которому я думал, что он заслужил ответа.
Включены @alexis Вы корректны при работе в одной файловой системе, но ситуация становится более сложной, когда nfs смонтировала файловые системы.
Неясно от OP точно, какое соединение версий nfs машин/серверов/клиентов включены, но я думал, что было достаточно сказать, "Вам нужен лучший механизм синхронизации, чем "касание - комната" и действительно, OP предлагает это вид работ, но имеет 1 в 15k шансе отказа. Таким образом, я предложил или, найдите лучший способ синхронизировать или кодировать вокруг этого.
После небольшого расследования на предмете я нашел некоторые ссылки, которые действительно показывают "дефекты" в nfs, которые указывают, что удаление файла не работает как ожидалось через nfs. Больше, существует, различия между nfs v3, и v4, конкретно для обращения к этому дефекту также nfs4 мог, работая по-другому, но не делает или иначе он повредил бы совместимость с клиентами старшего возраста.
Этот документ nfs суммирует ситуацию, это описывает глупое, переименовывают, который был представлен для кодирования вокруг проблемы, и rfc 5661 NFS 4.1 обеспечивает более подробную информацию.
- редактирование 2
Извлечение одного абзаца из вышеупомянутых ссылок:
Из-за дизайна протокола NFS нет никакого пути к файлу, который будет удален из пространства имен, но все еще останется используемым приложением. Таким образом клиенты NFS должны эмулировать это использование, что уже существует в протоколе. Если открытый файл является несвязанным, клиент NFS переименовывает его к специальному имени, которое похоже на ".nfsXXXXX". Это "скрывает" файл, в то время как это остается используемым. Это известно, поскольку "глупый переименовывают". Обратите внимание, что серверы NFS не имеют никакого отношения к этому поведению.
Идея № 1 - альтернативный подход?
Вместо touch файл, что, если Вы ожидали mv обработайте для завершения вместо этого.
$ mv $tempDir $finishedCasesDir & # copy case to result directory
$ wait %1 && touch $finishedCasesDir/$caseName/done
Это только коснется файла когда mv процесс завершился.
Пример
Вот пример с помощью sleep управляйте как помогание для Вашего mv команда.
время начала
$ date
Thu Feb 13 21:23:33 EST 2014
запустите моделируемую команду "mv"
$ sleep 10 &
[1] 28561
мы затем "ожидаем" его для окончания
$ wait %1 && echo 'all done!'
[1]+ Done sleep 10
all done!
подтверждение, что мы ожидали ~10 secs.
$ date
Thu Feb 13 21:23:48 EST 2014
продолжить
$ ...boost program can then run...
Идея № 2 - проблема NFS?
На основе обратной связи от @Gilles я не понял, что Вы работали с этими файлами по NFS. Я полагаю, что Gilles на 100% корректен, я также встретился с подобными проблемами при работе с файлами по NFS, где процесс может все еще иметь доступ к смонтированному каталогу NFS, который Вы пытаетесь удалить. Когда Вы сделаете этот NFS будет обычно создавать a .nfsXXXX файл в каталоге, который помешает Вашим попыткам приложений Повышения удалить файл, так как это эффективно не пусто.
Примечание: Наличия оболочки, CWD которой (Текущий Рабочий Каталог) является подкаталогом в этом монтировании NFS, достаточно для порождения этой проблемы.
Можно читать больше об этой проблеме здесь в этой статье, названной: Каков этот .nfs файл и почему я не могу удалить его?.
выборка от вышеупомянутой статьи% echo test> foo
% tail -f foo
test
^Z
Suspended
% rm foo
% ls -A
.nfsB23D
% rm .nfsB23D
% ls -A
.nfsC23D
% lsof .nfsC23D
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tail 1257 robh 0r VREG 176,6 5 3000753 .nfsC23D
%
Уведомление: можно использовать инструмент lsof определить, какой процесс поддерживает дескриптор файла.
Ссылки
-
1я в настоящее время ожидаю
mvзавершаться без запаздывания&. Делаетmv &плюсwait %1действительно измените ситуацию, что касается файловой системы? – Christoph 14.02.2014, 10:25 -
2@Christoph - на основе Вашего описания, что Ваше повышение базирующееся приложение C не может удалить каталог, b/c
mvпо-видимому, не закончил опустошать каталог, предшествующий, я сказал бы, попробуйте его и посмотрите. – slm♦ 14.02.2014, 11:06 -
3То же исключение, выданное
remove_all. Это не означает, что мое предыдущее обходное решение действительно работает лучше (который, возможно, был удачей). – Christoph 14.02.2014, 11:35 -
4я вполне уверен, это не помогло бы, на самом деле он имеет больше шанса сбоя. Исходный код работал бы, если бы это не было для NFS: логически,
doneтолько создается послеmvзавершается. Я подозреваю, что существует.nfsXXXфайлы оставили позади на сервере, которые еще не удалены;doneсоздается локально, таким образом, это замечено локально без распространения в прямом и обратном направлениях к серверу. – Gilles 'SO- stop being evil' 14.02.2014, 17:45 -
5@Gilles - спасибо я думаю, что Вы мертвы на этом NFS проблемы, я добавил это к моему также. – slm♦ 14.02.2014, 18:12
mvна самом деле завершено перед возвратом? – Christoph 13.02.2014, 13:38