Beyond Deleted Files: How Operating Systems Reveal Digital Evidence

Mita Wankhede — Thu, 22 Oct 2026 17:57:20 +0000

Exploring the digital traces left behind by everyday computer activity

Introduction: Is a deleted file really gone?

Imagine that a confidential document disappears from a computer just before a security investigation begins. The Recycle Bin is empty, the file cannot be found through File Explorer, and the person using the computer claims that nothing unusual happened.

Does that mean the evidence has disappeared?

Not necessarily.

Everyday computer activity can leave traces in several places, including filesystem metadata, system logs, application records, and information maintained while programs are running. Even when a file is deleted, some information associated with it may remain recoverable, depending on how the storage device and filesystem handle deletion and whether the relevant data has been overwritten.

This is where digital forensics becomes important. Digital forensics is the process of collecting, examining, and interpreting digital information to understand events involving a computer or another electronic device.

An operating system (OS) is more than an interface that allows us to open applications and manage files. It coordinates processes, memory, storage, users, and hardware. Some of the information it maintains can help investigators reconstruct parts of what happened on a system.

However, there is an important distinction: finding a digital trace is not the same as proving exactly what happened. Understanding both the usefulness and the limitations of these traces is essential to reliable digital investigation.

1. Why is an operating system useful in a digital investigation?

An operating system manages many activities that take place on a computer. Depending on its configuration, software, and version, it may record or maintain information about those activities.

For example, consider a user who signs in, opens a document, launches an application, modifies a file, and shuts down the computer. Different components of the system may retain different pieces of information about this sequence.

Some useful sources include:

Filesystem metadata: Information associated with files, such as names, sizes, and timestamps.
System and security logs: Records of selected system events, authentication activity, and security-related actions.
Process information: Details about programs running on the system, including information that may be available while a process is active.
Memory: Temporary information held in RAM while the computer is operating.
Application data: Records created by browsers, office applications, and other software.

The National Institute of Standards and Technology (NIST) discusses operating-system data alongside filesystem, network, and application data as potential sources for computer investigations. The precise sources available depend on the system and the investigation. [1]

The key idea is that evidence is often distributed across multiple sources. An investigator may need to combine them rather than rely on a single file or log entry.

2. Five types of digital traces

2.1 System and security logs

Logs are records of events that an operating system or application has been configured to record.

On Windows, Event Viewer provides access to different event logs, including Windows Logs and security-related records. Depending on the audit policy, the system may record events associated with logons, account management, policy changes, or process activity. [2]

On Linux systems, logs may be available through system logging services, journal facilities, or files under locations such as /var/log. The exact arrangement varies by distribution and configuration.

What can logs help establish?

Suppose a security team is investigating unusual activity at 9:15 PM. A relevant log entry might show that an account authenticated successfully around that time. Other records could indicate that a system service started or that a security policy changed.

When combined, such records may help investigators establish a timeline of selected events.

What are the limitations?

Logs do not automatically record everything a user does. Some event categories may not be enabled, records may be overwritten under retention policies, and logging services or systems may be misconfigured. In some circumstances, an attacker may also alter or delete records.

Furthermore, a successful login event does not establish which human was physically using the computer. A person may have left a session unlocked, for example.

Microsoft's audit-policy guidance illustrates why the events available to an investigator depend on which activities an organization chooses to monitor. [2]

2.2 Filesystem metadata

A filesystem organizes data on a storage device and maintains information needed to locate and manage files.

Depending on the filesystem, relevant metadata may include a filename, file size, timestamps, permissions, and information about the file's storage allocation.

These details can help answer questions such as:

When was a file recorded as modified?
What permissions were associated with it?
Is there evidence that a file or directory existed?
Do available timestamps fit the proposed sequence of events?

But timestamps require careful interpretation. A file's modification time is not necessarily the time at which someone first created it, downloaded it, or viewed it. Copying files, changing system clocks, and differences in software behavior can complicate interpretation.

Filesystem metadata should therefore be treated as one source of evidence rather than a complete history of a user's actions.

2.3 Process and program information

A process is an instance of a running program. Operating systems manage processes and allocate resources to them.

On Linux, the /proc pseudo-filesystem exposes information about running processes and other kernel-managed system information. Process-specific directories can contain details associated with individual process IDs. [3]

On Windows, process-related information may be available through operating-system facilities, diagnostic tools, security auditing, and other monitoring software. The information preserved for later analysis depends on the records that were enabled and collected.

Imagine an investigation into a suspicious program. A record showing that the program executed at a particular time could help establish part of the timeline. Its executable path, associated account, or other available details might provide additional context.

However, the fact that a process ran does not establish everything it did. A process record alone may not reveal which files it accessed, whether it successfully transmitted data, or whether a human deliberately launched it.

Another important distinction is between live system information and historical records. Information available from a running process may disappear when that process exits or the computer shuts down unless it was separately recorded or captured.

2.4 Memory artifacts

Random-access memory (RAM) temporarily stores information used by a running computer. This can include active program data and other information needed during execution.

In certain investigations, a properly collected memory image may provide evidence that is unavailable from ordinary files alone. Depending on the system state and tools used, memory analysis may reveal information about running processes, loaded components, network connections, or other activity.

Memory analysis is particularly relevant when investigators need to understand a computer's state while it is running.

But memory is volatile. Its contents change continuously, and shutting down a computer normally destroys much of the information held in RAM. Capturing memory also changes the system to some extent, so collection procedures matter.

A memory image is not a complete recording of everything that has ever happened on a computer. It is a snapshot of available information at a particular time, interpreted using appropriate methods.

2.5 Deleted-file remnants

Deleting a file does not always mean that every byte associated with it is immediately erased.

In some filesystem and storage situations, deletion makes the relevant space available for reuse. Data may remain until it is overwritten or otherwise removed. Forensic examination may sometimes recover portions of deleted files or associated metadata. NIST's forensic guidance discusses unallocated storage space and residual data as potential sources of information. [1]

This is the origin of the common question: Can investigators recover a deleted file?

The honest answer is: sometimes.

Recovery depends on several factors, including the filesystem, storage technology, deletion method, encryption, subsequent disk activity, and whether the data has been overwritten. Features such as solid-state drive garbage collection and TRIM can also affect recoverability.

Even when data is recovered, it may be incomplete, corrupted, or difficult to associate confidently with a particular event.

NIST's scientific review of digital investigation techniques specifically warns that deleted-file recovery may produce extraneous material and that investigators must understand the limitations of their methods. [4]

Therefore, neither of these assumptions is reliable:

Every deleted file can be recovered.
A deleted file can never be recovered.

The actual result depends on the circumstances.

3. Windows vs. Linux: Where might investigators look?

Both Windows and Linux can provide useful sources of digital evidence, but their logging systems, filesystem implementations, tools, and configurations differ.

Evidence source	Windows	Linux
System and security logs	Event Viewer and Windows event logs	System journal and distribution-specific log files
Process information	Process inspection and configured auditing or monitoring	`/proc` and process inspection tools
Filesystem information	Filesystem metadata and timestamps	Filesystem metadata and timestamps
User and authentication activity	Security events, if appropriately configured	Authentication and system logs, depending on configuration
Deleted data	Recovery may be possible depending on filesystem and storage conditions	Recovery may be possible depending on filesystem and storage conditions

This table provides a general overview, not a guarantee that any particular artifact will exist on a computer.

For example, a Windows system may not have recorded detailed process activity if the relevant auditing was not enabled. A Linux machine may have limited historical information if its logs were not retained or forwarded to another system.

Likewise, two computers running the same operating system may preserve different amounts of evidence because their owners have configured them differently.

The practical lesson is that investigators must understand the specific operating system, its version, its configuration, and the tools used to examine it.

4. A hypothetical investigation: Reconstructing a suspicious event

Consider a fictional company investigating the disappearance of a confidential report.

The security team notices that the report is missing from its expected location. One employee's account appears in a relevant login record, and a suspicious program may have been executed around the same period.

The team needs to determine what can be established from the available information.

Step 1: Establish the scope

The investigators identify the relevant computer, approximate time window, accounts, and systems that may contain related records.

They document the initial condition of the system and follow authorized evidence-preservation procedures. In a real investigation, collection must be performed carefully to reduce unnecessary changes to potential evidence.

Step 2: Examine available logs

The team reviews relevant authentication, security, and system records.

Suppose a record shows that the employee's account authenticated at 9:00 PM. This establishes that the system recorded an authentication event for that account, assuming the record is authentic and correctly interpreted.

It does not, by itself, establish who was physically present.

Step 3: Examine file-related evidence

The team reviews the report's available metadata, backups, and other authorized sources.

Suppose a file-related record indicates that the report was modified shortly before it disappeared. This may help narrow the timeline, but the meaning of the timestamp must be evaluated in context.

Step 4: Investigate program activity

A relevant process record may indicate that a particular program executed around the same time.

The investigators compare that information with the file-related records and other available evidence. They avoid assuming that the program caused the disappearance merely because the two events occurred close together.

Step 5: Correlate independent evidence

The team constructs a timeline showing the source and timestamp of each relevant observation. It then looks for agreement, contradictions, gaps, and alternative explanations.

For instance, if a separate server audit record documents a file operation involving the report, that may provide additional support for a particular explanation.

The investigators also consider whether timestamps use different time zones or clocks and whether records could have been altered.

What is the conclusion?

The investigation may establish a plausible sequence of events, or it may remain inconclusive.

That is not necessarily a failure. A responsible investigation distinguishes confirmed observations from interpretations and clearly explains what remains unknown.

This scenario is hypothetical. It illustrates an investigative approach and does not describe a real incident or claim that a particular set of artifacts would necessarily exist.

5. Why digital evidence can be misleading

Digital forensics is powerful, but evidence must be interpreted carefully. Several limitations can affect an investigation.

Missing records: An event may not have been logged, or its record may have been deleted or overwritten.

Timestamp problems: Incorrect system clocks, time-zone differences, copying, and software behavior may complicate the timeline.

Incomplete recovery: A recovered file may contain only fragments, and a search tool may not identify every relevant artifact.

Ambiguous attribution: An account, process, or device identifier does not automatically identify the human responsible for an action.

Changing technology: Operating systems and applications evolve. An artifact's meaning can vary across versions, and investigative tools must keep pace.

Alternative explanations: Two events occurring close together in time does not prove that one caused the other.

NIST's review emphasizes that digital investigations cannot guarantee discovery of all evidence and that the meaning of artifacts can change as software evolves. [4]

These limitations lead to a useful principle: an artifact is an observation, not automatically a conclusion.

A log entry may support an explanation. Several independent records may strengthen it. Contradictory evidence may weaken it. Investigators must consider all of these possibilities before reaching a conclusion.

6. A simple framework for evaluating digital traces

To make the analysis more systematic, we can use a practical framework called the Digital Trace Reliability Checklist.

This is a proposed learning framework for this article, not an established forensic standard or a validated scoring system.

For every artifact, ask five questions:

Source: Where did the information come from?
Meaning: What does the artifact directly show?
Limitations: What information is missing, uncertain, or potentially misleading?
Corroboration: Can another independent source support or contradict the interpretation?
Conclusion: What can reasonably be stated without going beyond the available evidence?

Consider how the checklist applies to three examples:

Artifact	What it may show	What it cannot establish alone
Login event	An account authenticated at a recorded time	The identity of the person physically using the computer
File timestamp	A recorded time associated with a file operation or metadata field	The complete history of who accessed the file and why
Process record	A program was recorded as running or executing	Every action the program performed or its intent

This framework encourages careful reasoning rather than jumping from an observation to an accusation.

It also highlights why corroboration matters. Independent evidence can make an interpretation stronger, although multiple records may still share the same underlying source or limitations.

7. How operating-system knowledge helps beyond forensics

Understanding operating systems is useful even for students who do not intend to become digital-forensics specialists.

For software developers, it provides insight into processes, memory, filesystems, permissions, and application behavior.

For cybersecurity professionals, it helps explain how to investigate suspicious activity, configure useful logging, and recognize gaps in monitoring.

For system administrators, it supports troubleshooting, auditing, and incident response.

For students preparing for technical interviews, it connects academic concepts such as process management, memory management, file systems, and access control to practical situations.

Digital forensics is therefore a useful example of how foundational operating-system knowledge can be applied to real-world problems.

Conclusion: The importance of evidence, not assumptions

A missing file does not necessarily mean that every trace has disappeared. Operating systems and applications may preserve useful information in logs, metadata, process records, memory, and storage remnants.

But these sources have limitations. Some records may never have been created, some information may be lost, and some recovered artifacts may be incomplete or ambiguous.

The goal of digital forensics is not simply to find traces. It is to interpret them responsibly, preserve their context, and distinguish what the evidence demonstrates from what an investigator merely suspects.

For anyone studying information technology, this offers an important lesson: understanding how an operating system works can reveal not only how computers perform tasks, but also how we investigate their behavior when something goes wrong.

The next time you delete a file, remember that deletion is a technical operation, not a guarantee about what information will remain recoverable. Whether any trace survives depends on the system and circumstances.

And in digital investigations, what matters most is not just finding a trace, but understanding exactly what it can—and cannot—tell us.

References

National Institute of Standards and Technology (NIST). Guide to Integrating Forensic Techniques into Incident Response (SP 800-86).

https://csrc.nist.gov/pubs/sp/800/86/final
Microsoft Learn. System Audit Policy Recommendations.

https://learn.microsoft.com/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
Linux Kernel Documentation. The /proc Filesystem.

https://docs.kernel.org/filesystems/proc.html
Lyle, J. R., et al. (2022). Digital Investigation Techniques: A NIST Scientific Foundation Review. National Institute of Standards and Technology.

https://www.nist.gov/publications/digital-investigation-techniques-nist-scientific-foundation-review

Disclaimer: This article is for educational purposes. Actual forensic investigations require appropriate authorization, suitable tools, documented procedures, and consideration of applicable legal and organizational requirements.

DEV Community: Mita Wankhede