📊 stat Command

What's happening: Stat displays complete file metadata. Line 1 - File name: The target file. Line 2 - Size/Blocks: Size is 1024 bytes, using 8 blocks (blocks are typically 512 bytes). IO Block shows filesystem block size. Line 3 - Device/Inode: Device ID (802h = hexadecimal, 2050d = decimal), unique inode number, and hard link count. Line 4 - Permissions: Shows both octal (0644) and symbolic (-rw-r--r--) permissions, plus owner UID/name and group GID/name. Lines 5-8 - Timestamps: Access (last read), Modify (last content change), Change (last metadata change), Birth (creation - not all filesystems support this). Why this matters: These details are crucial for debugging permission issues, understanding file history, forensic analysis, and verifying file integrity.

What's happening: The -c flag allows custom format strings. First example: Shows just filename and size in a concise format. Second example: Multi-line custom output with labels. Newlines in the format string are preserved. Third example: CSV-style output for multiple files - perfect for importing into spreadsheets or databases. Format sequences like %n (name), %s (size), %y (modify time) extract specific fields. Scripting power: Custom formats make stat output parseable by scripts. Instead of parsing human-readable output, you can extract exact fields needed. This is essential for automation, monitoring, and data collection scripts.

What's happening: The -t (terse) flag outputs all information in a single line with space-separated fields - ideal for parsing with awk, cut, or other text processing tools. Field order: name, size, blocks, mode (hex), uid, gid, device, inode, links, major, minor, atime, mtime, ctime, birth, blocksize. Second example: Shows parsing terse output with awk. Fields are positional: $1=name, $2=size, $5=uid, etc. Why terse mode: Consistent field positions make parsing reliable. Human-readable format varies and is hard to parse. Terse format is stable and designed for scripts. Use case: Collecting file statistics across many files for analysis, generating reports, or monitoring file changes over time.

What's happening: Demonstrates the three timestamps and what triggers their updates. First: Fresh file via touch - all three timestamps are identical. Second: Appending content updates Modify and Change (but not Access in this example). Third: Changing permissions (metadata) updates only Change time, not Modify or Access. Understanding timestamps: Access (atime): Last read. Note: Many systems mount with relatime/noatime for performance, so atime may not update on every read. Modify (mtime): Last content modification. This is what ls -l shows. Change (ctime): Last metadata change - permissions, ownership, hard links, or content. Cannot be set manually (unlike atime/mtime). Forensic importance: Timestamp analysis helps determine file history, detect tampering, investigate incidents, and understand system activity.

What's happening: The -f flag shows filesystem information instead of file information. Output details: ID is the filesystem ID, Namelen is maximum filename length, Type shows filesystem type (ext4, xfs, btrfs, etc.), Block size information, Total/Free/Available blocks (Available accounts for reserved blocks), Total/Free inodes. Second example: Custom format for filesystem stats. %n = path, %T = type, %a = available blocks, %b = total blocks. Use cases: Monitoring disk space at filesystem level, checking filesystem type before operations, verifying mount points, capacity planning, and troubleshooting space issues. Available vs Free: "Free" is total unused space, "Available" is what non-root users can use (some space is reserved for root).

What's happening: Stat handles symbolic links specially. Without -L: Shows information about the link itself - size is the length of the target path string, type is "symbolic link", permissions are always 777 (symbolic links have no meaningful permissions). With -L (dereference): Follows the link and shows information about the target file (/etc/passwd). Now you see the actual file's size (2048 bytes), type (regular file), real permissions (644), and owner (root). Why this matters: Links can mask true file properties. Checking the link itself tells you about the link; checking with -L tells you about the target. For broken links (target doesn't exist), -L will fail with an error. Use case: Verifying link targets, debugging broken links, understanding file relationships, and checking actual vs. apparent permissions.

What's happening: This script finds files exceeding 100MB. Step 1: find locates all files (null-separated for safety with special characters). Step 2: stat -c %s extracts exact size in bytes. Step 3: Compare against threshold. Step 4: For large files, convert size to human-readable format with numfmt and print. Step 5: Sort by size (largest first) using sort -rh. Why stat instead of ls: Stat gives precise byte counts and is more scriptable. stat -c %s is cleaner than parsing ls -l output. Practical uses: Disk space analysis, finding bloat, identifying files to archive, capacity planning, and quota management.

What's happening: This script verifies backup integrity by comparing file metadata. Comparisons: Size comparison catches incomplete backups or corruption. Modification time comparison detects if backup is outdated. Why not just size: Size alone isn't sufficient - a corrupted file might have the same size. However, mismatched size definitively indicates a problem. Enhancement possibilities: Add checksum comparison (md5sum/sha256sum) for content verification, check permissions with stat -c %a, verify ownership, or check inode numbers for hard links. Real-world use: Automated backup verification, disaster recovery prep, compliance checking, and ensuring backups are current before critical operations.

What's happening: First script: Monitors important config files by logging their modification times. %Y gives Unix timestamp (seconds since epoch) for easy calculations. %y gives human-readable format for logging. Run this via cron to track config changes over time. Second script: Checks if a critical file (/etc/passwd) was modified recently. Calculates age by subtracting file mtime from current time. If modified in last hour (3600 seconds), triggers alert. Use cases: Security monitoring (unauthorized changes to system files), compliance auditing (who changed what when), change management (tracking configuration updates), and troubleshooting (correlating file changes with system issues).

What's happening: Hard links: Multiple directory entries pointing to the same inode (same physical data). First example: Both files have identical inode numbers (12345678) and link count (2), proving they're hard links to the same data. Modifying either file affects both since they share data. Second script: Finds all hard links by searching for matching inode numbers. %i = inode, %d = device (important: inodes are unique per device, not globally). find -inum locates all files with that inode. -xdev prevents crossing filesystems. Why this matters: Hard links save space (one copy of data, multiple names), but can be confusing. Deleting one hard link doesn't delete the data until all links are removed. Stat reveals the link count, helping understand file relationships. Use cases: Space analysis, understanding backup structures, file deduplication verification, and troubleshooting "file won't delete" issues.