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