tar: file changed as we read it
Categories:
Resolving 'tar: file changed as we read it' Errors

Understand and fix the common 'tar: file changed as we read it' error, often encountered during backups or archiving, especially in dynamic environments like those using Makefiles.
The error message tar: file changed as we read it is a common frustration for system administrators and developers alike. It typically occurs when the tar utility attempts to archive a file, but the file's content or metadata (like size or modification time) changes between the moment tar starts reading it and when it finishes. This can lead to corrupted archives or incomplete backups, making it crucial to understand its causes and solutions.
Understanding the Root Cause
This error is a race condition. tar reads files sequentially. If a file is modified by another process while tar is in the middle of reading it, tar detects this inconsistency and reports the error. This is particularly prevalent in environments where files are frequently updated, such as log directories, temporary file systems, or during active build processes managed by tools like make.
sequenceDiagram
participant Tar as tar process
participant File as Target File
participant Other as Other process
Tar->>File: Start reading file A
activate File
Other->>File: Modify file A (e.g., append data)
deactivate File
Tar->>File: Continue reading file A
activate File
File-->>Tar: Detects inconsistency (size/checksum mismatch)
deactivate File
Tar-->>Tar: Report 'file changed' errorSequence diagram illustrating the race condition leading to 'tar: file changed as we read it' error.
Common Scenarios and Solutions
The solution often depends on the context in which the error occurs. Here are some common scenarios and their respective remedies:
1. Archiving Dynamic Files (e.g., Logs, Databases)
When dealing with files that are constantly being written to, such as log files or active database files, direct tar archiving is problematic. The file will almost certainly change during the read operation.
1. Solution: Use Snapshots or Copy-on-Write
If your file system supports snapshots (e.g., LVM, ZFS, Btrfs), create a snapshot of the volume containing the files. Archive from the snapshot, then delete the snapshot. This provides a consistent view of the file system at a specific point in time.
2. Solution: Stop Services Temporarily
For critical application data (like databases), the safest approach is often to temporarily stop the service that writes to the files, perform the tar operation, and then restart the service. This ensures data consistency.
3. Solution: Copy to a Temporary Location
For less critical files, you can copy them to a temporary location first, then tar the copied files. This reduces the window of opportunity for changes, though it doesn't eliminate it entirely if the original file is very large and changes rapidly.
# Example: Copying logs before tarring
mkdir /tmp/logs_backup
cp /var/log/* /tmp/logs_backup/
tar -czf logs_archive.tar.gz /tmp/logs_backup
rm -rf /tmp/logs_backup
Copying files to a temporary directory before archiving.
2. Makefile and Build Process Integration
In Makefile contexts, this error often arises when tar is used to package build artifacts, but some files are still being generated or modified by other make rules or background processes. This can happen if dependencies are not correctly specified or if parallel builds are in progress.
Makefile dependencies are a common culprit. Ensure that all files included in the tar archive are fully built and stable before the tar command executes.1. Solution: Ensure Build Completion
Make sure that the tar command is executed only after all necessary build steps have completed and all target files are stable. This might involve adding explicit dependencies in your Makefile.
2. Solution: Use make -j1 for Archiving
If you suspect parallel make jobs are causing the issue, try running the archiving step with make -j1 (single job) to ensure sequential execution. This is a workaround, not a permanent fix for dependency issues.
3. Solution: Archive a Staging Directory
Similar to the general solution, copy all final build artifacts to a dedicated staging directory after the build is complete, and then tar that staging directory. This isolates the tar operation from the active build process.
all: package
build_artifacts: compile link
# Commands to build your project
package: build_artifacts
mkdir -p $(STAGING_DIR)
cp $(BUILD_OUTPUTS) $(STAGING_DIR)/
tar -czf my_project.tar.gz -C $(STAGING_DIR) .
rm -rf $(STAGING_DIR)
Makefile example ensuring build completion before archiving a staging directory.
3. Ignoring Specific Files or Directories
Sometimes, the error occurs for specific, known dynamic files (e.g., temporary files, sockets, named pipes) that you don't intend to archive anyway. In such cases, it's best to exclude them.
tar -czf archive.tar.gz --exclude='./temp_dir' --exclude='*.log' /path/to/source
Using --exclude to prevent tar from attempting to archive dynamic or temporary files.