# Test Case: LZMA Corrupted Data Handling

**Test ID**: TC110-lzma-corrupt  

**G5 fixture contract**: Use [G5-MANUAL-SETUP.md](G5-MANUAL-SETUP.md).
Its generated paths, source comparisons, structured corruption offsets, and
cleanup rules supersede placeholder examples in this file.
**Category**: Compression  
**Priority**: High  
**Regression**: None

## Objective
Verify proper error handling when LZMA compressed data is corrupted.

## Preconditions
- EROFS image with LZMA-compressed files
- `g5_fixtures.py` manifest proving algorithm 1, the target pcluster range,
  exact patch offset/length, and a valid superblock checksum
- FreeBSD 13.0+

## Test Steps
1. Create valid LZMA-compressed EROFS image
2. Use only the generated `lzma-partial-ref-corrupt.erofs`; do not apply blind
   or random offsets.
3. Attach and mount: `unit=$(mdconfig -a -t vnode -f test.img); mount -t erofs -o ro /dev/${unit} /mnt`
4. Run `timeout 20 read_probe expect-error /mnt/a.dat 5`.
5. Compare `/mnt/control.bin` from the same corrupted image with its source,
   then check cleanup, allocation count, dmesg, and responsiveness.

## Expected Results
- Mount succeeds (corruption not in superblock)
- Read returns EIO error
- Error logged to dmesg
- System remains stable (no panic)
- Other uncorrupted files still readable

## Verification Method
- Verify read fails with errno == EIO
- Check dmesg for LZMA decompression error
- Confirm system stability after error
- Verify other files still accessible

## Cleanup
```sh
umount /mnt
mdconfig -d -u "${unit#md}"
```

## Notes
Tests feature 60: LZMA error path with corrupted compressed data.
