Для очистки всего одной записи, Вам нужен другой флаг:
hash -d svnsync
-r
флаг не берет параметр и будет всегда удалять весь кэш.
(По крайней мере, в ударе 3.2.39 на Debian Lenny)
Инструмент, который Вы хотите, lsof
, который обозначает список открытые файлы.
Это имеет много опций, так проверьте страницу справочника, но если Вы хотите видеть все открытые файлы в соответствии с каталогом:
lsof +D /path
Это рекурсивно вызовет через файловую систему под /path
, поэтому остерегайтесь выполнения его на больших деревьях каталогов.
После того как Вы знаете, какие процессы имеют открытые файлы, можно выйти из тех приложений или уничтожить их с kill(1)
команда.
Я использую fuser
для такого рода вещи. Это перечислит, какой процесс использует файл или файлы в монтировании.
fuser
помогает только в конкретном случае, когда Вы хотите размонтировать файловую систему. Здесь проблема состоит в том, чтобы найти то, что использует определенный файл.
– Gilles 'SO- stop being evil'
13.04.2011, 22:09
fuser
не помогает здесь, потому что проблема состоит в том, чтобы найти все открытые файлы в дереве каталогов. Можно сказать lsof
показать все файлы и отфильтровать или заставить его рекурсивно вызвать; fuser
не имеет такого режима и должен быть вызван на каждый файл.
– Gilles 'SO- stop being evil'
14.04.2011, 10:57
fuser
работы будут списки. Попробовать fuser /var/log/*
, если какие-либо журналы будут открыты, то это скажет, у которые и кого есть он открытый. Если простой подстановочный знак, не будет работать, find
с или без xargs
сделает задание.
– BillThor
14.04.2011, 20:23
lsof
не был в моем пути в то время как fuser
был, позволяя мне найти, что незаконный идентификатор процесса уничтожает, таким образом, +1+thanks.
– stevesliva
13.10.2015, 22:48
Вот решение:
ls -a
.xyz
filevi .xyz
и посмотрите, что за содержимое файлаps -ef | grep username
kill -9 job_ids
- где job_ids - значение 2-ой колонки соответствующего ошибочного содержимого в 8-ой колонкеУ меня была такая же проблема, построенная однострочник, начинающийся с рекомендации @camh:
lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs kill -9
Команда awk
захватывает PIDS. Команда tail
избавляется от надоедливой первой записи: «PID». Я использовал -9
при убийстве, у других могли быть более безопасные варианты.
иногда это результат проблем с подключением, поэтому я бы отключил файловую систему или каталог, который вы пытаетесь удалить:
umount / path
У меня возникла эта проблема, когда автоматический тест создал ramdisk. Команды, предложенные в других ответах, lsof
и fuser
, не помогли. После тестов я попытался размонтировать его, а затем удалить папку. Я действительно был сбит с толку целую вечность, потому что не мог от этого избавиться - я все время получал «Устройство или ресурс занято» !
Случайно узнал, как избавиться от рамдиска. Мне пришлось размонтировать его столько же раз, сколько я запускал команду mount
, т.е.
sudo umount path
Из-за того, что он был создан с помощью автоматического тестирования, он монтировался много раз, поэтому я не мог избавиться от него, просто размонтировав его один раз после тестирования. Итак, после того, как я много раз размонтировал ее вручную, она, наконец, снова стала обычной папкой, и я смог ее удалить.
Если у вас есть доступ к серверу, попробуйте
Deleting that dir from the server
Или выполните размонтирование и монтирование еще раз, попробуйтеumount -l
:отложенное размонтирование, если возникнут какие-либо проблемы при обычном размонтировании.
У меня тоже была эта проблема, когда
lsof +D path
:не дает выходных данных
ps -ef
:не дает соответствующей информации
В ответ на вопрос Прабхата выше, у меня была эта проблема в macos high sierra, когда я застрял в процессе encfs, перезагрузка решила ее, но это
ps -ef | grep name-of-busy-dir
Показал мне процесс и PID (второй столбец ).
sudo kill -15 pid-here
исправил.
Я часто сталкиваюсь с этим на серверах с сетевыми файловыми системами NFS. Я предполагаю, что это как-то связано с файловой системой, поскольку файлы обычно называются .nfs000000123089abcxyz
.
Мое типичное решение — переименовать или переместить родительский каталог файла, затем вернуться позже через день или два, и файл будет удален автоматически, после чего я могу удалить каталог.
Обычно это происходит в каталогах, в которые я устанавливаю или компилирую программные библиотеки.
/path
. Это - одна причина скрытых "открытых файлов". – camh 05.02.2014, 11:16