> ## Documentation Index > Fetch the complete documentation index at: https://filetrace.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Records, identifiers and history > The processes, sockets, flows, files, transfers and events that Filetrace records, the IDs that link them, what each byte count measures, and how long history lasts. Every Filetrace command reads the same set of records that the agent keeps in memory. Knowing what each record represents, how records refer to each other and how long they last makes the output of the commands, the JSON fields and the exported telemetry easier to interpret. ## Record types | Record | What it represents | Listed by | | - | - | - | | Process | A process that used the network, with its PID, parent, name, executable, user, cgroup and namespaces. | [`processes`](https://filetrace.mintlify.site/cli/processes), [`inspect process`](https://filetrace.mintlify.site/cli/inspect) | | Socket | One TCP or UDP socket, by its local and remote ends, with its state and byte counts. | [`connections`](https://filetrace.mintlify.site/cli/connections), [`inspect socket`](https://filetrace.mintlify.site/cli/inspect) | | Flow | One process's traffic with one remote endpoint on one socket. | [`flows`](https://filetrace.mintlify.site/cli/flows), [`inspect flow`](https://filetrace.mintlify.site/cli/inspect) | | File | A regular file that a thread read or sent, identified by device and inode. | [`inspect file`](https://filetrace.mintlify.site/cli/inspect) | | Transfer | File bytes attributed to a socket, or sent bytes no file accounts for, with method and confidence. | [`files`](https://filetrace.mintlify.site/cli/files), [`transfers`](https://filetrace.mintlify.site/cli/transfers) | | Event | One record of the agent's log, in order: process, socket, network and transfer events. | [`events`](https://filetrace.mintlify.site/cli/events) | ## Identifiers Sockets, flows and transfers have stable IDs that the `inspect` command takes: | ID | Column | JSON field | Example | | - | - | - | - | | Socket ID | `SOCKET` in `connections` | `socket_id` | `16` | | Flow ID | `FLOW` in `flows` | `flow_id` | `7` | | Transfer ID | `ID` in `transfers` | `transfer_id` | `tr_3` | ```bash theme={null} filetrace connections --format quiet --limit 1 # prints a socket ID filetrace inspect socket 16 ``` A process is identified by its PID and a file by its path, so `inspect process 1245` and `inspect file /var/www/video.mp4` need no ID. ## File identity A file is identified by device and inode, not by path. Its path, size and owner are read from the kernel when the file is first seen and are labels only: a file renamed during a transfer is still the same file. When a file is deleted and its inode number is given to a new file, the new file is a separate file with its own path; the agent notices the end of the old one through the `__destroy_inode` probe. Inside a container on overlayfs, device and inode are those of the overlay mount. On btrfs, files in different subvolumes can share an inode number. ## Three byte counts For a file, three numbers describe different things: | Field | Meaning | | - | - | | `file.size` | The size of the file when it was first seen. | | `transfer.bytes_read` | What the sending thread read from the file (read-write transfers). | | `transfer.bytes_sent` | What the socket accepted from this file. This is the `BYTES` column of `files`. | Byte counts are what the local socket accepted. They are not bytes on the wire and not what the remote end acknowledged. ## Lifetime and time ranges A record in `files` or `transfers` covers a transfer's whole observed lifetime. A record in `events` covers one collection interval: byte counts are gathered in the kernel and collected several times a second, so a network or transfer event carries the bytes of one such interval, not of one system call. `--since` and `--until` select records by when they were active. The byte counts of a selected record still cover its whole observed lifetime. ## Ownership of accepted connections A socket created by `accept(2)` has no owning process until that process sends or receives on it. ## Bounded, in-memory history All state is in memory and bounded: * Every table has a fixed capacity, set in the `[limits]` section of the configuration, and forgets its least recently updated entry when it is full. * The event log has a fixed size (1 MB by default, `[agent] event_log_size`) and keeps separate shares for transfers, network events and process events, so a flood of one kind does not push out the others. * History starts when the agent starts and is not kept across restarts. Every report that depends on history says from when it reaches: ```text theme={null} History starts at 2026-11-11 12:00:04, when the agent started. Nothing earlier is kept. ``` [`filetrace stats`](https://filetrace.mintlify.site/cli/stats) shows how full each table is: ```text theme={null} COLLECTOR Event queue: 4.00 MB Peak utilization: 0% Event log: 1.00 MB, holding 163 events Processes: 20 of 4,096 Sockets: 19 of 16,384 Flows: 13 of 16,384 Files: 17 of 16,384 Transfers: 4 of 16,384 ``` ## Lost events If the kernel produces events faster than the agent reads them, some are lost. Lost events are counted in `watch`, `stats` and `doctor`, and a transfer during which events were lost is marked `incomplete` in JSON and with `*` after its confidence in tables. A query whose time range contains lost events exits with code `9`, meaning the answer may be incomplete. See [Overhead and sizing](https://filetrace.mintlify.site/guides/performance.md) for how to avoid loss. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.