كيفية حذف الملفات المرفوعة؟

[zogstrip]

@anon47420739

So an image with an upload record that was never actually posted or was edited out of a comment would be deleted automatically. That correct?

That is correct.

@anon47420739

This doesn’t seem like it’s being “served”, it seems like it’s being uploaded. Is that not the case?

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”.

@anon47420739

• I deleted the link at the dropbox end and immediately it stopped being viewable in the post.

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

@anon47420739

there is no pencil - to test this:

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.

@anon47420739

The behavior in point one runs counter to the post here , if you look through the first post edit history you can see a .gif.

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

Those were not uploaded. Just linked.

[anon47420739]

Thank you.

@zogstrip

Those were not uploaded. Just linked.

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.

[anon47420739]

@anon47420739

Clicking “View Image” from the context menu takes me to a community.signalusers address, is that expected behavior?

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

@anon47420739

So an image with an upload record that was never actually posted or was edited out of a comment would be deleted automatically. That correct?

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

[Falco]

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

[anon47420739]

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.

[sebastianh (Rebastion)]

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…

[tanius]

كان عليّ أيضًا حذف ملف تم تحميله بطريقة ما. لا يوجد لدينا مهمة التنظيف مفعلة لأن بعض الملفات تأتي من استيراد من برنامج منتديات مختلف ولم تتم الإشارة إليها بعد في المشاركات المستوردة بشكل صحيح. لذلك، احتجت إلى إيجاد طريقة يدوية. ما يلي يعمل ولكنه ليس أنيقًا …

1. تأكد من أن التحميل المعني لم يعد موجودًا في الإصدار الحالي لأي مشاركة. بهذه الطريقة، ستعتبره Discourse يتيمًا ولن تسبب مشاكل عند حذفه.

2. استخدم إضافة مستكشف البيانات (Data Explorer plugin) أو طريقة أخرى للاستعلام عن قاعدة بيانات 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
   

3. في قاعدة البيانات أو باستخدام وحدة تحكم Rails لـ Discourse، احذف السجل المعني من جدول uploads بواسطة معرف التحميل الخاص به. هنا أستخدم وحدة تحكم Rails:

   Upload.where(id: 16384).first.delete
   

4. احذف الملف المرتبط بما في ذلك جميع الإصدارات المحسّنة (إن وجدت، ينطبق على الصور) من نظام الملفات عبر SSH. لاحظ العلامة النجمية المضافة قبل امتداد الملف لالتقاط الإصدارات المحسّنة أيضًا، والتي لها لاحقة هنا. بالطبع،

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

[anon98107012]

@anon47420739

الرابط محذوف ولكن الصورة لا تزال في سجل التعديل

هاه! يبدو أن الصورة المشار إليها في هذا المنشور لم يتم التقاطها بواسطة هذه الإعدادات:

config/site_settings.yml

لماذا لم يتم حذفها؟

هل يمكنني أيضًا أن أتساءل لماذا يقوم Discourse “بتحميل” ملف مرتبط مثل رابط Dropbox هنا؟ النقطة من ربط ملف معين ستكون غالبًا في الاحتفاظ بالتحكم في المحتوى.

[LotusJeff (Jeff Cocking)]

مع تغيير إعادة تسمية post_uploads إلى upload_references، لم يعد استعلام SQL المذكور في الخطوة 2 صالحًا. الكود المحدث هو:

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