file_scan_results
This table stores the results of malware or virus scanning performed on
uploaded files. It provides a detailed audit trail beyond the summary
scan_status stored on the file itself.
Purpose
The purpose of this table is to capture file scanning outcomes from the security pipeline so the system can determine whether a file is safe to use and retain an audit trail of scan activity.
What this table does
- Stores the output of security scanning for files
- Tracks which engine performed the scan
- Provides detailed context when a file is infected or scan fails
- Supports operational troubleshooting and security review
Why this table is defined
DirtView needs virus or malware scanning for uploaded files. A single status field on the file record is useful, but a dedicated scan-results table provides better traceability and operational visibility.
Columns
| Column | Type | Required | Description | Example |
|---|---|---|---|---|
id |
uuid | Yes | Primary key for the scan result | scan_001 |
file_id |
uuid | Yes | File that was scanned | file_001 |
engine |
text | Yes | Scanning engine or service name | clamav |
status |
text | Yes | Result of the scan | clean |
signature_name |
text | No | Threat signature if malware was detected | Win.Test.EICAR |
details |
jsonb | Yes | Raw or structured scan details | {"duration_ms": 342} |
scanned_at |
timestamptz | Yes | Timestamp when the scan completed | 2026-04-11 10:03:00+00 |
Relationships
- file_id → files.id
How it is used
- Written by the scanning worker or backend service
- Used to determine whether a file can be exposed to end users
- Used for support/security review when a scan fails or detects an issue
Access and security
- This table is operationally sensitive
- Most tenant users should not need raw scan details
- Use it to support quarantine and release workflows
Example scenarios
Scenario 1: Clean upload
A PDF upload is scanned and marked clean before being made available.
Scenario 2: Infected file
An uploaded file is flagged and remains blocked from download or processing.
Scenario 3: Scan failure
A worker error occurs and the failure details are stored for retry and investigation.
Notes and assumptions
- A file may have more than one scan result over time
- The latest authoritative status may still be mirrored on
files.scan_status - Consider indexing
(file_id, scanned_at desc)