맞습니다.
새로운 수정 이력을 생성하지 않고 님이 닌자처럼(즉각적으로) 게시물을 편집했기 때문에 판단하기 어렵습니다. 이 게시물의 첫 번째 버전에는 "edited.png"만 포함되어 있습니다.
이것은 님이 이미지를 업로드한 것이 아니라 링크만 연결했다는 것을 시사합니다.
네, 님이 게시물을 너무 빨리 편집했기 때문입니다. 여기에는 300초의 유예 기간이 있으며, 이 기간 내에 편집을 하면 게시물의 새 버전이 생성되지 않습니다.
원본(raw)을 보면 이미지가 단순히 드롭박스 링크임을 알 수 있습니다.
그것들은 업로드된 것이 아닙니다. 단순히 링크만 걸려 있는 것입니다.
감사합니다.
해당 링크들은 이미 오래전에 삭제되었는데, 그렇다면 이 .gif 파일들이 더 이상 표시되지 않아야 하지 않나요? 컨텍스트 메뉴에서 "이미지 보기"를 클릭하면 community.signalusers 주소로 이동하는데, 이것이 정상적인 동작인가요?
테스트를 위해 약 300초 후에 이 부분을 수정하고, 잠시 후 링크를 삭제하겠습니다.
deleted.png
수정 #2
링크는 삭제되었지만 이미지 수정 이력에는 여전히 남아 있습니다. 아마도 Upload 기록이 없어서 자동 정리 과정에서 제거되지 않는 것 같습니다.
이미지는 https://global.discourse-cdn.com/meta/original/3X/1/0/101f03af29f12ea30e1226eb96a02c3ed2f6d2ef.png 에 호스팅되어 있습니다. 드롭박스가 아닙니다.
주변을 살펴본 결과, download_remote_images_to_local이 활성화된 상태에서는 로컬에 저장되는 것이 정상적인 동작인 것 같습니다. 관련 설정은 이 것으로 보입니다.
따라서
이 부분은 이전 게시글에서 보여준 바와 같이 이 유형의 업로드에는 적용되지 않는 것 같습니다. 틀렸다면 지적해 주세요.
사이트 설정에서 clean up uploads가 활성화되어 있으면, clean orphan uploads grace period hours가 지난 후 업로드된 파일이 삭제됩니다.
빠른 답변 감사합니다!
clean up uploads는 upload 레코드가 있는 모든 이미지를 포함하는 일반적인 설정으로 보입니다. 맞나요? download_remote_images_to_local로 인해 생성된 것만 그런 것이 아니라요. 맞다면, 자동 정리로 인해 삭제되지 않는 일반 이미지 업로드 사례를 사이트에서 찾을 수 있을 것입니다.
해결책으로 제안할 수 있도록 clean orphan uploads grace period hours가 여기서 어떻게 설정되어 있는지 물어봐도 될까요? 아니면 기본값이 있는 건가요?
그들이 해당 설정을 활성화하기로 결정하면, 과거 게시물에 적용하기 위해 별도로 해야 할 일이 있을까요?
수정
명확하게 하기 위해, 여기서는 이것이 문제가 아니라 설정을 켜야 한다는 것입니다. 나중에 "이걸 활성화해야 해요!"라고 했다가 "이미 활성화되어 있어요!"라는 답변을 받고 우스워지는 것은 원치 않으니까요.
저도 업로드된 파일을 찾아볼 수 있는 장소를 급하게 찾아보게 되었습니다. (MediaWiki에서 익숙한 기능인데) 같은 파일이 두 번, 세 번, 네 번이나 중복 업로드되는 경우가 많아서, 예전에 올렸다가 잃어버리거나 삭제된 파일이 어디 있는지 궁금할 때가 있거든요. 그러면 다시 올리는 대신 그 파일을 링크로 걸 수 있을 텐데 말이죠… 파일 브라우저 같은 기능이 필요하다는 생각이 드네요… 
또한 업로드된 파일을 어쨌든 삭제해야 했습니다. 일부 파일은 다른 포럼 소프트웨어에서 가져온 것이며, 가져온 게시물에 아직 올바르게 참조되지 않아 정리(cleanup) 작업이 활성화되어 있지 않기 때문입니다. 따라서 수동으로 삭제하는 방법을 찾아야 했습니다. 다음 방법은 작동하지만 깔끔하지는 않습니다 …
해당 업로드가 현재 버전의 어떤 게시물에도 더 이상 존재하지 않는지 확인하십시오. 이렇게 하면 Discourse가 이를 고아(orphaned) 파일로 간주하여 삭제 시 문제를 일으키지 않습니다.
Data Explorer 플러그인 또는 다른 방법을 사용하여 Discourse 데이터베이스를 쿼리하여 고아 업로드를 나열하고, 관련 항목을 찾아 그 upload_id와 파일명을 기록하십시오. 관련 쿼리:
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN post_uploads ON uploads.id = post_uploads.upload_id
WHERE post_uploads.post_id IS NULL
ORDER BY created_at DESC
LIMIT 100
데이터베이스 또는 Discourse용 Rails 콘솔을 사용하여 upload ID를 기준으로 uploads 테이블에서 해당 레코드를 삭제하십시오. 여기서는 Rails 콘솔을 사용합니다:
Upload.where(id: 16384).first.delete
SSH를 통해 파일 시스템에서 관련 파일 및 모든 최적화 버전(이미지의 경우 해당)을 삭제하십시오. 여기서는 접미사가 붙는 최적화 버전도 함께 포착하도록 파일 확장자 앞에 와일드카드를 추가한 것에 유의하십시오. 물론,
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
아! 이 게시물에서 언급된 이미지가 이 설정에 의해 포착되지 않는 것 같습니다:
왜 삭제되지 않았을까요?
또한, Discourse가 여기의 Dropbox 링크와 같은 링크된 파일을 왜 "업로드"하는지 궁금합니다. 특정 파일에 링크를 걸는 목적은 콘텐츠에 대한 제어권을 유지하는 경우가 많기 때문입니다.
post_uploads를 upload_references로 이름 변경하면서 2단계에 나열된 SQL 쿼리는 더 이상 유효하지 않습니다. 업데이트된 코드는 다음과 같습니다:
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN upload_references ON uploads.id = upload_references.upload_id
WHERE upload_references.target_id IS NULL
ORDER BY created_at DESC
LIMIT 100