유사한 주제들을 살펴보며 잠재적으로 일치하는 미해결 사례를 수집하던 중, 이러한 상황이 고아(Orphan) 파일로 처리되지 않고 영구적으로 삭제되지 않아 법적 문제를 일으킬 수 있는 좋은 예를 하나 찾았습니다:
2016년에 있었던 또 다른 유사한 상황입니다:
이러한 조건들은 악용이나 불법 콘텐츠 업로드를 위한 표적 공격에 큰 틈을 만들어 줍니다. 관리자가 삭제된 것으로 생각하더라도 서버에서 영구적으로 제거되지 않을 수 있기 때문입니다. 물론 파일 시스템에서 단일 파일을 수동으로 삭제하는 것은 가능하지만, 특히 자동 정리 프로세스를 나타내는 GUI 설정이 있고, 또한 модератор(모더레이터)는 보통 서버에 직접 접근 권한이 없는 상황에서, 이러한 기본적인 요구 사항에 대해 사람들이 그러한 방법을 강요당해서는 안 된다고 생각합니다. 또한 삭제된 여러 주제에 흩어져 있는 대량의 파일에 대해 수동 삭제는 실용적이지 않습니다.
이것은 실제 버그 리포트로 충분한 근거가 될까요? 우리 측의 잘못된 구성 가능성은 아직 배제하지 않고 있지만, 오류 메시지가 전혀 없다는 점과 다른 모든 것이 정상적으로 작동하는 것에 대해 당혹감을 느끼고 있습니다. 저는 문제 해결과 테스트에 점점 더 많은 시간을 보내면서 Discourse와 그 구성 요소에 대한 지식을 쌓아 왔으므로, 몇 가지 안내를 주신다면 이 기이한 동작을 유발하는 모서리 케이스(Corner case) 세부 사항을 파악하는 데 도움을 줄 수 있을 것이라고 생각합니다. 지금 @zogstrip 님을 핑(Ping)하는 것이 괜찮을까요?
임시 해결책으로, 모든 업로드 파일을 톰스톤(Tombstone) 디렉토리로 수동으로 이동한 후 업로드 복구 방법을 사용하여 고아 파일이 아닌 파일만 원래의 올바른 디렉토리로 복원하는 것이 가능한가요? 실제로 오늘 이 작업을 시도해 보았지만 rake uploads:recover_from_tombstone 명령이 어떤 파일도 복원하지 않았습니다. 이것이 업로드 데이터베이스 항목의 더 큰 문제를 가리키는 것일 수 있을까요?