시스템에서 깨진 심볼릭 링크를 모두 삭제하는 데 단점이 있습니까?

Linux 시스템의 모든 파일을 반복하고 해당 파일에 대한 일부 메타 데이터를 생성하는 스크립트를 실행 중이며 깨진 심볼릭 링크에 도달하면 오류가 발생했습니다.

나는 * nix를 처음 사용하지만 파일을 링크하고 끊어진 링크가 존재하는 방법에 대한 주요 아이디어를 얻습니다. 내가 아는 한, 그들은 거리에서 쓰레기와 같습니다. 내가 제거하는 프로그램이 패키지 관리자가 존재하고 속해 있거나 업그레이드에 남은 것을 알기에 충분히 똑똑하지 않은 것. 처음에는 실행중인 스크립트를 건너 뛰기 시작했습니다. 그런 다음 '우리가 여기있는 동안 항상 삭제할 수 있습니다'라고 생각했습니다.

우분투 14.04 (Trusty Tahr)를 실행 중 입니다. 나는 어떤 이유도 볼 수 없지만 개발 시스템을 통해 이것을 실행하기 전에 실제로 이것이 끔찍한 아이디어 일 수있는 이유가 있습니까? 깨진 심볼릭 링크는 내가 알지 못하는 어떤 목적으로 사용됩니까?

깨진 심볼릭 링크에는 여러 가지 이유가 있습니다.

• 더 이상 존재하지 않는 대상에 대한 링크가 작성되었습니다.
  해결 : 깨진 심볼릭 링크를 제거하십시오.
• 이동 된 대상에 대한 링크가 작성되었습니다. 또는 대상을 기준으로 이동 한 상대 링크입니다. (상대적 심볼릭 링크가 나쁜 생각임을 암시하는 것은 아닙니다. 반대의 경우가 있습니다. 절대 심볼릭 링크는 대상이 이동했기 때문에 더 오래 사용되는 경향이 있습니다.)
  해결 방법 : 의도 한 대상을 찾고 링크를 수정하십시오.
• 링크를 만들 때 실수가있었습니다.
  해결 : 원하는 대상을 찾고 링크를 수정하십시오.
• 링크는 이동식 디스크, 네트워크 파일 시스템 또는 현재 마운트되지 않은 다른 저장 영역에있는 파일로 연결됩니다. 해결 : 없음, 링크가 항상 끊어지지는 않습니다. 저장 영역이 마운트되면 링크가 작동합니다.
• 링크는 의도적으로 일부만 존재하는 파일에 대한 링크입니다. 예를 들어, 파일은 프로세스의 캐시 된 출력으로, 정보가 오래되었을 때 삭제되지만 명시 적 요청시에만 재생성됩니다. 또는 링크가 비어있을 때 삭제되는받은 편지함에 대한 링크입니다. 또는 해당 주변 장치가 연결된 경우에만 존재하는 장치 파일에 대한 링크입니다. 해결 : 없음, 링크가 항상 끊어지지는 않습니다.
• 링크는 다른 스토리지 계층에서만 유효합니다. 예를 들어, chroot jail에서만 유효하거나 NFS 서버에 의해 내보내지고 서버 또는 일부 클라이언트에서만 유효합니다.
  해결 : 없음, 링크가 어디에서나 끊어지지 않습니다.
• 대상을 도달하기 위해 디렉토리를 통과 할 권한이 없기 때문에 링크가 끊어졌지만 적절한 권한을 가진 사용자에게는 끊어지지 않습니다.
  해결 : 없음, 모든 사람에게 링크가 끊어지지는 않습니다.
• 이 링크는 vinc17에서 인용 한 Firefox 잠금 예제 에서와 같이 정보를 저장하는 데 사용됩니다 . 이 방법으로 수행하는 한 가지 이유는 심볼릭 링크를 원자 적으로 채우는 것이 더 쉽다는 것입니다. 다른 방법은 없지만 파일을 원자 적으로 채우는 것은 더 복잡합니다. 임시 이름으로 파일 내용을 만든 다음 제자리로 옮기고, 충돌로 남겨진 오래된 임시 파일을 처리합니다. 또 다른 이유는 심볼릭 링크가 일반적으로 일부 파일 시스템의 inode 내부에 직접 저장되어 파일의 내용을 읽는 것보다 빠르게 읽는 것입니다.
  해결 : 없음 이 경우 링크를 제거하면 해 롭습니다.

심볼릭 링크가 첫 번째 범주에 속하는 것으로 판단되면 계속 진행하여 삭제하십시오. 그렇지 않으면, 기권하십시오.

디렉토리를 재귀 적으로 탐색하고 파일 내용을 관리하는 프로그램은 일반적으로 손상된 심볼릭 링크를 무시해야합니다.

매달린 모든 심볼릭 링크를 맹목적으로 제거하지 마십시오. 그것들은 단지 일부 정보를 전달하기 위해 존재할 수 있으며 심볼릭 링크 생성이 원자 적이므로 일반 파일보다 안전 할 수 있습니다.

예를 들어 Firefox는 "IP_address : + PID"와 같은 형식의 심볼릭 링크 인 잠금 파일 "lock"을 만듭니다.

양쪽 fnord 과 개틀링 (복잡한 - 투 - 구문 분석 구성 파일을 사용하여 마이크로 소프트 Windows 레지스트리를 사용하여 IIS, 또는 아파치, 말, 반대)을 자신의 구성 데이터베이스로 유닉스 파일 시스템을 사용하는 웹 서버.

예를 들어 가상 호스트는 디렉토리 일 뿐이므로 새 가상 호스트를 만드는 것은 간단합니다.

mkdir www.example.com:80

제공 할 파일을 구성 하시겠습니까?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

CGI로 실행할 파일과 서비스 할 파일을 구성 하시겠습니까?

chmod a-x plain_file.html
chmod a+x cgi_script.html

그리고 마지막으로 (이 질문과 관련이 있습니다) 리디렉션을 구성합니까?

ln -s 'http://www.google.com/?q=awesome+query+site:www.example.com' search.html

이제 search.html아무데도 가리지 않는 심볼릭 링크 가 있지만 사이트 작업에 중요합니다.

심볼릭 링크는 특정 파일 시스템 위치 또는 이름에서 강제로 작성하기 위해 아직 비어있는 위치를 가리킬 수 있습니다.

따라서 맹목적으로 제거하지 마십시오.

오래된 심볼릭 링크를 삭제하는 데있어 중요한 단점은 링크가 어디에 사용되는지에 대한 참조를 잃어 버릴 수 있다는 것입니다.

존재하지 않는 파일 " send_to"에 대한 심볼릭 링크가 /Users/myname/tmp있다고 가정 /Users/myname/tmp합니다.

심볼릭 링크와 나는 파일이 된 곳을 알고 구성 할 수 있습니다. 예를 들어,이 경우 임시 디렉토리임을 알 수 있으며 "수정"해야 할 경우 임시 디렉토리를 대상으로 고려해야합니다.

마찬가지로 " my_config" 로 바뀌는 링크 " " 는 이름이 confirm_file로 바뀌 었 /etc/conf_file으므로 conf_file여전히 유용한 정보입니다. /etc디렉토리 로 이동하여 ls호출 한 파일 conf_file이 누락 된 것을 보았지만 confirmation_file링크가 있으면 수정하기에 충분한 정보가있을 수 있습니다.

리눅스 커맨드 라인 에서 인용 (리눅스 초보자를위한 최고의 책, 무료로 다운로드 할 수 있습니다 ) :

시나리오 설명 : 프로그램은“foo”라는 파일에 포함 된 일종의 공유 리소스를 사용해야하지만“foo”는 버전이 자주 변경됩니다. 파일 이름에 버전 번호를 포함시키는 것이 좋으므로 관리자 나 다른 이해 당사자는 어떤 버전의 "foo"가 설치되어 있는지 확인할 수 있습니다. 문제가 있습니다. 공유 리소스의 이름을 변경하면 새 버전의 리소스가 설치 될 때마다이를 사용할 수있는 모든 프로그램을 추적하고 새 리소스 이름을 찾도록 변경해야합니다. 전혀 재미없는 것 같습니다.

심볼릭 링크가 하루를 저장하는 곳입니다. 파일 이름이 "foo-2.6"인 "foo"버전 2.6을 설치 한 다음 간단히 "foo-2.6"을 가리키는 "foo"라는 심볼릭 링크를 만듭니다. 프로그램이 파일을 열 때 " foo”, 실제로“foo-2.6”파일을 엽니 다. 이제 모두가 행복합니다. "foo"를 사용하는 프로그램에서 찾을 수 있으며 실제 버전이 설치되어 있는지 확인할 수 있습니다. "foo-2.7"로 업그레이드 할 때 파일을 시스템에 추가하고 심볼릭 링크 "foo"를 삭제 한 다음 새 버전을 가리키는 새 링크를 작성하십시오. 이렇게하면 버전 업그레이드 문제가 해결 될뿐만 아니라 시스템에 두 버전을 모두 유지할 수 있습니다. “foo-2.7”에 버그가 있고 (그 개발자들에게 피해를 입혔습니다!) 이전 버전으로 되돌려 야한다고 상상해보십시오. 다시,

따라서 아니오, 기호 링크를 삭제하지는 않을 것입니다. 두통이 계속 발생하고 시스템을 심각하게 망칠 위험이 있습니다.