Skip to content

Laszlo Mako

My feedback

1 result found

  1. 95 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Laszlo Mako supported this idea  · 
    An error occurred while saving the comment
    Laszlo Mako commented  · 

    I found that this is partly because:
    A, file records are not even soft deleted in the database, even if the post they were originally attached to IS deleted
    B, files are physically kept in the data directory

    Other than that the used storage will grow indefinitely, it doesn't even seem to make sense. Deleting the post will make the attachment disappear from the UI and unavailable/unusable for all users.

    Notice below, how the post has "deleteat" timestamp set in public.posts table, but it is 0 on the attachment in public.fileinfo. public.fileinfo.deleteat should either be set by a database trigger to the same timestamp that of the original post's delete time, or set on both records from code as well as the file physically deleted. We already have the file location stored in public.fileinfo, so it doesn't seem very complicated.

    mattermost=> select p.id post_id, p.deleteat post_delete_time, f.name file_name, f.size file_size, f.deleteat file_delete_time from public.posts p join public.fileinfo f on f.postid = p.id where p.deleteat > 0 and coalesce(f.deleteat,0) = 0 order by p.deleteat;
    -[ RECORD 1 ]----+----------------------------
    post_id | gfhts4kfybfh9ecn68mdksjjsc
    post_delete_time | 1500029064303
    file_name | test file
    file_size | 15
    file_delete_time | 0
    -[ RECORD 2 ]----+----------------------------
    post_id | nxkeu31sdpfepy1t3nmuy758by
    post_delete_time | 1500086864483
    file_name | 15000846037071752086964.jpg
    file_size | 6204621
    file_delete_time | 0

Feedback and Knowledge Base