fix: treat qpdf exit code 3 (warnings only) as VALID in PDF check
- exit 0 and exit 3 both map to VALID; only exit 2 is a structural error
- error detail now includes first matching error line from qpdf output
fix: add EXIT trap so encryption flag and temp files are always cleaned up
- changed signal trap from to
- EXIT fires for any bash exit including syntax errors and unexpected crashes
- clean_up() now runs first to prevent re-entry / infinite loop
- applies to recover_bad_signature.sh (where the flag matters most),
restore_bad_signature.sh and recreate_bad_signature.sh
feat: check optional validation tools at startup and offer apt install
- new check_optional_validation_tools() prompts [j/N] in interactive mode
- covers: imagemagick (identify), ffmpeg (ffprobe), mp3val, flac, vorbis-tools (ogginfo)
feat: use optional tools for deeper file validation when available
- PNG / GIF / BMP / TIFF: identify -regard-warnings (full decode) with magic-byte fallback
- MP4 / MOV / M4V: ffprobe -show_streams (container parse) with ftyp-box fallback
- MP3: new dedicated case — mp3val frame check with ID3/sync-word fallback
- FLAC: new dedicated case — flac --silent --test with fLaC-signature fallback
- OGG / OGA / OGV / OPUS: new dedicated case — ogginfo with OggS-signature fallback
Affects: recover_bad_signature.sh, restore_bad_signature.sh, recreate_bad_signature.sh
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GfXh5sRbEaXiEX6KjAPivc
After the user confirms with YES, each script now prints the paths of
the two temporary files that are written continuously during the run,
so they can be monitored with tail -f without having to know the paths
by heart. Affects scan_, recover_, restore_, recreate_bad_signature.sh.
recreate shows per-account log file names since it writes one per user.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GfXh5sRbEaXiEX6KjAPivc
unzip -tq on a password-protected archive tries to open /dev/tty to
prompt for the password. Inside a tmux session this generates SIGTTIN,
which stops the process (ps state T). A stopped process cannot receive
SIGTERM, so timeout waited indefinitely for a child that would never exit.
Fix: wrap all unzip calls with setsid so the process runs in a new
session without a controlling terminal. The /dev/tty open then fails
immediately with ENXIO and unzip exits with a non-zero code instead of
blocking. Additional hardening:
- timeout -k 5: send SIGKILL 5 s after SIGTERM as a last resort
- < /dev/null: also cut off stdin as a secondary safeguard
- exit 137 (128+9, SIGKILL) treated as timeout alongside 124
- error output matching "password"/"encrypt"/"need PK compat" reported
as UNVERIFIED instead of INVALID
Affects: recover_bad_signature.sh, restore_bad_signature.sh,
recreate_bad_signature.sh
unzip -tq can block indefinitely on very large or partially corrupt
ZIP archives (stalls in I/O rather than exiting with a CRC error).
All three scripts that call validate_recovered_file() are affected:
recover_, restore_, recreate_bad_signature.sh.
Both the quick check (unzip -tq) and the verbose error pass (unzip -t)
are now wrapped with `timeout 120`. Exit code 124 (timed out) is
reported as UNVERIFIED with a hint for manual follow-up; any other
non-zero exit is still reported as INVALID with the first error line.
Betroffen: scan_, recover_, restore_, recreate_bad_signature.sh
und diagnose_share_key.sh
Bei Accounts mit sehr vielen bzw. sehr großen Dateien konnte der
jeweilige Pro-Account-Durchlauf länger als eine Stunde dauern und
wurde dann von PHP mit "Maximum execution time of 3600 seconds
exceeded" abgebrochen - mitten im Lauf, ohne jedes Ergebnis.
- su -c "$PHP_BIN ..." ruft PHP jetzt zusätzlich mit
-d max_execution_time=0 auf.
- Das allein reicht nicht: Nextclouds eigenes lib/base.php setzt
beim Bootstrap unbedingt (fest einprogrammiert, nicht
konfigurierbar) set_time_limit(3600) und überschreibt damit den
CLI-Flag wieder. Daher zusätzlich direkt nach dem require von
lib/base.php ein erneutes set_time_limit(0) in jedem der fünf
eingebetteten PHP-Scripte, das Nextclouds Reset seinerseits
rückgängig macht.
Kein Verhaltensunterschied für kleine/normale Accounts, betrifft
nur die maximale Laufzeit pro Account.
chris
