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
