如何删除已上传的文件?

That is correct.

Can’t tell since you ninja edited your post which did not create a new revision. The first version of this post only has “edited.png”.

Which makes me think that you linked the image and did not upload it.

Yes, because you edited your post too quickly. We have a grace period window of 300 seconds here in which if you make an edit, it won’t create a new version of the post.

If you look at the raw, you see that the images are merely links to dropbox

Those were not uploaded. Just linked.

3 个赞

Thank you.

The underlying links have long been deleted - Shouldn’t that mean these .gif should seize appearing? Clicking “View Image” from the context menu takes me to a community.signalusers address, is that expected behavior?

Testing, I’ll edit this out in ~300 seconds and shortly after delete the link.

deleted.png


Edit#2

The link is deleted but the image persists in the edit history, perhaps it doesn’t have an Upload record as it isn’t removed by the automatic cleanup.

It’s hosted at https://d11a6trkgmumsb.cloudfront.net/original/3X/1/0/101f03af29f12ea30e1226eb96a02c3ed2f6d2ef.png. Not dropbox.

1 个赞

I suppose, looking about, that it is held locally is expected behavior when download_remote_images_to_local is enabled. I think that’s the relevant setting.

So this

isn’t functioning for this type of upload, as demonstrated in my previous post. Correct me if I’m wrong.

1 个赞

The upload will be deleted if the site setting clean up uploads is enabled, after clean orphan uploads grace period hours.

5 个赞

Thanks for the quick response!

clean up uploads sounds like a general setting that would capture all images with an upload record, is that correct? Not just those present due to download_remote_images_to_local. If true, I should be able to find examples on the site of regular image uploads that aren’t being removed as a result of the automatic cleanup.

You mind me asking what the clean orphan uploads grace period hours is set to here so I can offer it as a solution. Or does it come with a default?

If they decide to enable that setting, will they need to do anything to apply it to past posts?


Edit
Just for the sake of being explicit, the thinking here is that this isn’t an issue but that a setting needs to be switched on. I just don’t want to go back and say “You need to enable this!” and they say “It is enabled!” I’ll look silly.

1 个赞

I also caught myself frantically looking for a place to browse uploads (familiar with it from MediaWiki) because I just know stuff gets double triple and quadruple uploaded, and sometimes I wonder where a file was that I uploaded once a while ago but maybe lost or deleted so I can link to it instead of re-uploading it yet again… I guess there is something to be said about a file browser… :slight_smile:

1 个赞

我还必须以某种方式删除一个已上传的文件。我们没有启用清理任务,因为有些文件来自另一个论坛软件的导入,并且尚未在导入的帖子中正确引用。因此,我需要找到一种手动方法。以下方法有效,但并不理想……

  1. 确保相关上传不再是任何帖子当前版本的一部分。这样,Discourse 会将其视为孤立文件,并在您删除它时不会引起麻烦。

  2. 使用 Data Explorer 插件 或其他方法查询 Discourse 数据库,列出孤立的上传文件,找到相关的那个,并记下其 upload_id 和 filename。相关查询:

    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
    
  3. 在数据库中或使用 Discourse 的 Rails 控制台 通过其 upload ID 删除 uploads 表中相关的记录。这里我使用 Rails 控制台:

    Upload.where(id: 16384).first.delete
    
  4. 通过 SSH 删除文件系统中的关联文件,包括所有优化版本(如果有,适用于图像)。请注意,在文件扩展名前添加了通配符,以捕获此处带有后缀的优化版本。当然,

    cd /path/to/discourse/shared/public/
    find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
    
1 个赞

嗯!看起来此帖子中引用的图片并未被这些设置捕获:

为什么它没有被删除?

我还想知道为什么 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