5.7.189. Bugzilla::Extension::RedHat::bin::find_deleted_attachments¶
5.7.189.1. NAME¶
find_deleted_attachments.pl
5.7.189.2. SYNOPSIS¶
find_deleted_attachments.pl –user <login> [–user <login> …]
--help|h Display help text
--man Display man page
--user=login Email of an account to check (repeatable)
5.7.189.3. DESCRIPTION¶
Read-only report. For each user given, finds every attachment they ever
created and checks whether the attachments table still has a row for it.
Attachments are found via the auto-posted “Created attachment NNNNN”
comment (type = CMT_ATTACHMENT_CREATED, extra_data holds the attach
id) rather than the comment text, because DeSpamComments only rewrites
thetext when it stubs a comment out - type and extra_data are
untouched either way, so this works whether or not the comment was ever
nuked.
Why a missing row means what it means: Bugzilla::Attachment::remove_from_db(the normal delete-attachment action, from the UI or bz-admin) always
keeps the attachments row - it wipes attach_data and sets
isobsolete = 1, never removes the row. The only place in this codebase
that hard-deletes an attachments row entirely is
Bugzilla::Extension::RedHat::Job::DeSpamComments::_insinkerator(DELETE FROM attachments WHERE submitter_id = ?), run as part of the
manage_user_access repudiate action. So an attach id reported here as
missing was deleted by a repudiate action, not by a normal delete, and is
only recoverable from a database backup taken before that repudiate ran -
there is nothing left in the live database to reconstruct it from.
This script makes no changes and is safe to run directly against production.
This documentation undoubtedly has bugs; if you find some, please file them here.
