How 7-Zip Handles Files Modified During Compression

When source files are modified during compression, 7-Zip handles the operation based on operating system file locks, active command-line switches, and file stream consistency. In most cases, modifying a file during archiving leads to sharing violations, inconsistent data states, or read warnings, typically resulting in 7-Zip completing the archive with a non-zero exit code to alert the user to potential data integrity issues.

Default File Locking Behavior

By default, 7-Zip requests standard read access to files. If another process opens a file with exclusive write locks, 7-Zip cannot read the file. In the graphical interface, this triggers an error dialog, while the command-line interface reports:

System error: The process cannot access the file because it is being used by another process.

In this scenario, 7-Zip skips the locked file, compresses the remaining files, and exits with Exit Code 1 (Warning) or Exit Code 2 (Fatal Error), depending on the severity and total number of skipped items.

Behavior with the Shared Write Switch (-ssw)

To bypass read locks on files currently being written by other processes, 7-Zip includes the -ssw (Share write mode) switch. When this switch is active:

  1. Shared Read Access: 7-Zip opens the file handle even if another process maintains an open write handle.
  2. Sequential Streaming: 7-Zip reads the file sequentially from start to finish. It does not monitor the file for real-time changes made by other applications while reading.
  3. Inconsistent Snapshots: If an application modifies sectors of the file that 7-Zip has already passed, those updates are excluded. If an application modifies sectors ahead of the read pointer, the new data is included. This phenomenon, known as a "torn read," can create a corrupted or logically inconsistent state inside the archive for databases, log files, or active virtual disks.

File Size Changes During Read Operations

If an external process alters the file size while 7-Zip is streaming its data, the outcome depends on whether the file expanded or shrunk:

  • File Truncation (Shrinking): If the file becomes smaller while 7-Zip reads it, 7-Zip encounters an unexpected End-of-File (EOF) before reaching the initially queried file length. This produces a file read error, and 7-Zip flags the archive entry as incomplete or failed.
  • File Expansion (Growing): If the file grows, 7-Zip generally stops reading at the byte length recorded when the file handle was opened, or it reads up to the new EOF depending on how the file system updates the stream boundary. Any discrepancy between cached metadata and actual compressed payload length will register as a warning.

Checksums and Integrity Verification

7-Zip records file metadata (such as timestamps and original size) alongside a CRC32 or SHA-256 checksum calculated from the stream it actually processed. If a file changes while being read:

  • The checksum stored in the archive reflects the stream 7-Zip received, not necessarily a valid snapshot of the original file on disk.
  • 7-Zip will successfully test the archive later against its own internal checksum, but extracting the file may yield application-level errors if the data was torn or half-written during the initial compression pass.

Because 7-Zip lacks a native Volume Shadow Copy Service (VSS) engine on the desktop version, relying on standard compression for active files carries data corruption risks. For live files that change continuously:

  • Create a Volume Shadow Copy (VSS) snapshot prior to running 7-Zip to freeze the filesystem state.
  • Pause or stop writing services before beginning the compression task.
  • Inspect 7-Zip exit codes in automated scripts (where 0 indicates success, 1 indicates warnings/skipped files, and 2 indicates fatal errors) to catch modification-induced read failures.