“rm -rf”를 사용하여 디렉토리를 삭제하려고했는데 “Directory not empty”메시지가 나타납니다.
Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x 5 benjaminhocking staff 170 Aug 27 14:46 .
drwxr-xr-x 3 benjaminhocking staff 102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty
Finder를 사용하여 같은 것을 시도하면 (폴더를 휴지통으로 드래그) 메시지가 나타납니다.
“empty_directory”항목이 사용 중이므로 작업을 완료 할 수 없습니다.
나는 xattr -d com.apple.quarantine
순전히 미신에서 벗어나 려고 노력했지만 좋지 않았습니다.
컨텍스트의 중요한 부분은이 디렉토리가 처음에 터미널을 잠그기 전에 발행 한 “make clean”명령에 의해 삭제 된 디렉토리에 있었기 때문입니다. 그 후에 다른 프로그램의 절반 이상이 Skype, 결국에는 OS 자체를 포함하여 실행이 중단되었습니다. 전원 키를 길게 눌러 컴퓨터를 재부팅해야했습니다.
추가 편집 : 내가 중단 한 또 다른 중요한 정보는 이것이 암호화 된 폴더 à la에서 발생했다는 것 encfs
입니다. 암호화 된 부분에서 해당 폴더를 추적하고 삭제할 수있었습니다. 나는 왜 내가 평소처럼 암호 해독 된 측면에서 그것을 할 수 없었는지 아직도 모른다. 누구든지 그것에 대한 좋은 대답이있는 경우를 대비하여 지금은 대답하지 않습니다.
답변
컴퓨터를 재부팅하고 rmdir(1)
다시 실행 하십시오.
$ rmdir -r empty_directory/
그래도 작동하지 않으면 다음을 시도하십시오.
$ rm -rf empty_directory/
OS X가 lsof(8)
사전 설치되어 있다고 가정하여 여전히 작동하지 않으면 다음을 입력하십시오.
$ lsof +D empty_directory/
이 디렉토리에있는 파일이 프로그램에서 사용 중인지 알려줍니다. HFS + 파일 시스템은 사용중인 파일을 삭제할 수 없다고 생각합니다. 어쨌든 killall(1)
이 디렉토리 나 그 안에 숨겨진 파일을 사용하는 실행 파일. Finder가 empty_directory
디렉토리에 숨겨진 파일을 사용하여 폴더보기 설정을 저장했을 수 있습니다. 이것이 도움이되기를 바랍니다.
PS : lsof(8)
설치되어 있는지 확인하려면 다음을 입력하십시오.
$ lsof
출력이 다음과 같으면 lsof(8)
시스템에 설치된 것입니다.
lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz
해당 디렉토리에 숨겨진 암호화 파일 또는 암호화 키 파일이 있는지 확인하십시오. 이들은 범인이 될 수 있습니다.
답변
디스크 유틸리티를 사용하여 디스크를 복구하면이 문제가 해결되었습니다.
답변
이런 일이 발생하고 모든 항목을 삭제하려면 확실하게 사용하십시오. sudo rm -rf directory/
답변
디렉토리 (rm -r dirname)를 제거하는 동안이 오류가 발생했습니다. 이 스레드를 검색하고 발견하기 전에 여기에서 읽은 모든 제안을 이미 시도했습니다. 원래 질문에서 의도하지 않은 추가 포인트가 있는지 여부는 알 수 없지만 제 경우에는 문제의 근원이었고 해결책은 다음과 같습니다.
-
해당 디렉토리가 네트워크 마운트 디스크에 있음
-
어떤
ls
파인더 또는 명령 줄에서 시도가 아무 것도 없었다하지만.
및..
-
ssh
명령을 통해 네트워크 디스크 서버에 로그인하여 확인ls -al
했습니다. 결과 에는 확장 된 보안 정보가있는 여러 항목 (.
및 모드 에 추가됨)이 및 에 추가되었습니다 ...
.__filename
+
나는이가 생각, 또는 처음 사용할 때 년 전에 생성 맥 OSX 언급 한 파일과 유사 cp -R
, tar
또는 cpio
파일의 아카이브 또는 이동 그룹은. 나는 그들이 이동 후 일부 파일 속성을 올바르게 재설정하는 데 사용되었다고 추론했습니다-아마도 uid / gid, mode, acls, mtime / utime / ctime 등; 난 정말 모르겠어요 – 한 속성을 하지 그 시간 전에 해당 명령에 의해 제대로 리셋을 받고 (나는 OSX 포함하는 데 사용되는 것을 기억 mvmac
하고 cpmac
이 전에 명령이 문제를 해결하려면 .__filename
파일 유형의 일반적인 형태를 사용하는 경우 나타나기 시작 cp
, tar
등).
내장, USB 또는 Firewire 드라이브에 파일을 쓸 때 이러한 파일을 삭제하는 데 문제가 없었습니다. 네트워크 디스크에서 처음 발견 한 것입니다. 마운트의 클라이언트 쪽에서는 완전히 감지 할 수 없지만 서버 쪽에서 보면 모든면에서 정상입니다.
rm -rf dirname
네트워크 디스크 서버의 로그인에서 디렉토리의 내용과 함께 디렉토리를 올바르게 제거했습니다.
따라서 가치있는 것에 대한 또 다른 대답이 있습니다. 네트워크 디스크와 함께 누군가에게이 문제가 나타날 경우이 문제에 대한 또 다른 잠재적 인 해결책입니다.
답변
결과없이 여기에 모든 답변을 시도했습니다. 그러나 mv 명령을 사용하여 디렉토리를 옆으로 이동할 수 있었 으므로 계속 진행할 수있었습니다.
답변
나를 위해 일한 유일한 해결책은 /unix/234876/unable-to-delete-a-file-whatever-i-do 에서였습니다 .
/ tmp로 옮기고 다시 시작하십시오.
내가 시도한 다른 옵션은 다음과 같습니다.
- 디스크 유틸리티-응급 처치.
lsof +D bad_file
출력이 보이지 않았다.- sudo rm -rf
- 단일 사용자 터미널로 부팅 및
rm -rf
.
답변
독자의 이익을 위해 :
rm -rf
이런 경우 조심하십시오 ! 네트워크 공유 일 경우 다른 곳에서 문제를 일으킬 수 있습니다! 경고를 받았습니다!
거의 모든 경우 directory
에가 비어 있는 것 같으면 rmdir directory
또는를 사용하십시오 sudo rmdir directory
. 사용하지 마십시오 rm
(또는 del
Windows에서). 그래도 문제가 해결되지 않으면이 요청을 차단 한 원인을 찾아 수정 한 다음 다시 시도해야합니다 rmdir
.
OS-X는 모르지만 Unix / BSD 동작과 매우 유사하다고 생각합니다.
그것은 매우 가능성이 문제의 디렉토리 그냥이었다가 있다는 것입니다 마운트 지점 합니다 (encfs에서) 또는 (제거 할 디렉토리를 방지) 일부 부적절한 상태에서 읽기 전용 또는 붙어가 된 마운트 지점에있는. 이제 디렉토리를 강제로 제거하면 매우 나쁜 일이 발생할 수 있습니다.
좋은 경우에는 디렉토리가 실제로 비어 있으므로 제거하는 것 (마운트 등을 파괴하는 것)은 더 이상 해를 끼치 지 않았습니다. 나쁜 경우에는 비어 있지 않은 것 같습니다. 즉, 죽이고 싶지 않은 것을 버렸습니다. 이것은 모두 마운트 유형, 사용중인 드라이버 등에 따라 다릅니다. pp.
일이 합리적으로 잘 구현되면 일반적으로 나쁜 일이 발생하지 않습니다. 그러나 이것은 일반적인 경우가 아닙니다. 상황이 이미 이상한 상태에 있습니다. 즉, 무언가 잘못되었으므로 더 이상 혼합하지 마십시오! 무언가에 금이 가면 잘못 건 드리면 파손될 수 있습니다.
예를 들어 네트워크 공유에서 경쟁 조건에 도달하면 rm -rf
다른 사람이 공유에 복사 한 데이터를 제거 할 수 있습니다 .
그러나 rmdir
실제로 비어있는 디렉토리를 제거하는 것 외에는 절대로 해를 끼치 지 않습니다. NFS의 경우에는 mkdir
및 에서만 원자 동작을 보장 rmdir
하지만 다른 곳에서는 보장하지 않기 때문에 NFS에서도 마찬가지 입니다.
참고 사항 :
도구를 사용하여 마운트 포인트를 감지 할 수 있습니다 mountpoint directory
. 또는 출력을 살펴보고 mount
마운트를 찾으십시오. 그러나 적어도 리눅스에서는 이것이 거짓말을 할 수 있습니다. mountpoint
유틸리티를보다 안정적이지만 덜 편리하게 사용하십시오 .
이 경우 마운트 포인트를 찾았 으면 마운트 포인트를 마운트 해제 한 다음 디렉토리를 제거 할 수 있습니다.이 순서는 다음과 같습니다.
umount directory
rmdir directory
필요한 경우 sudo
평소처럼을 사용하십시오.
노트:
-
네트워크 공유는
rmdir
액세스 권한으로 인해 거부 될 수 있습니다 . -
rmdir
실패한 파일 시스템은 실패 전략에 따라 거부 될 수 있습니다 . 아마도이 경우에 합리적인 메시지를 보게 될 것입니다. -
Linux (및 아마도 최신 OS)에서는 다른 수단 (예 : 읽기 전용 마운트, SeLinux와 같은 기능 등)을 사용하여 액세스를 제한 할 수도 있습니다. 이것은 이것이 마운트 포인트라는 것을 알지 못하고 잘못된 것을 보지 못하지만 작동하지 않는다는 것을 의미합니다. 이 경우 다른 이유를 찾아야하며 OS에 매우 깊이 묻힐 수 있습니다. 합리적인 오류 메시지가 표시되면 도구에 따라 다릅니다. 또한
dmesg
Linux에서 와 같이 syslog / kernel-log를 살펴보십시오 (죄송합니다, OS-X에 해당하는 것을 모르겠습니다). -
필수 파일 잠금도 소스 일 수 있습니다. 이것은 Windows에서 일반적이지만 일반적으로 Unix는 아니며 디렉토리에 대해서는 들어 본 적이 없습니다. 필수 파일 잠금은 POSIX에서 다루지 만 선택 사항입니다.
-
그러한 경우에, 해당 디렉토리는 생각한 것과 다른 파일 시스템에 상주합니다. 명령을 사용하여 어느 것을 찾을 수 있습니다
df directory
(OS-X에서도 동일하다고 생각합니다). -
당신은 같은 도구를 사용하여 깊은 검사 할 수 있습니다
stat
또는statfs
디렉토리에. 그러나 이것들은 일반 사람들에게는 약간 낮은 수준이며, 종종 그러한 도구는 일반 사용자에게 잘 숨겨져 있습니다. -
디렉토리는 재미있는 이름의 파일을 가질 수 있습니다. 터미널 출력을 즉시 지우는 파일과 같이 존재하지 않는 것처럼 보입니다.
ls -al | less
MidnightCommander 와 같은 것을 시도 하거나 사용 하십시오mc
.
버그, 헥 소르, 외계인 또는 요정과 같은 더 이국적인 것들을 포함한 다른 가능성의 기차가 있습니다. 그러나 일반적으로 거기에서 시작하는 것이 현명하지 않습니다. 대신 “인간이 가장 끔찍하기 때문에”오류를 먼저 찾아보십시오.