From 44f143fbe84f1abcabbaba954e77f29df1527cf6 Mon Sep 17 00:00:00 2001
From: Christoph <ckubu@oopen.de>
Date: Tue, 15 Sep 2026 01:17:59 +0200
Subject: [PATCH] diagnose_share_key.sh: some changes on script output.

---
 diagnose_share_key.sh | 32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/diagnose_share_key.sh b/diagnose_share_key.sh
index a309d94..330bb20 100755
--- a/diagnose_share_key.sh
+++ b/diagnose_share_key.sh
@@ -48,17 +48,30 @@ usage() {
    fix - these are NOT signature problems, they are Server-Side
    Encryption KEY-MATERIAL problems (a per-user 'share key' for a file
    is either missing on disk or fails to decrypt with that user's
-   private key). This script accepts either a recovery_*.tsv or a
-   restore_*.tsv report as input.
+   private key).
+
+   \033[1mThis script accepts either of two report types as input, and\033[m
+   \033[1mevaluates a different row/status from each:\033[m
+
+         \033[1mrecovery_*.tsv\033[m report  (from recover_bad_signature.sh)
+            ->  evaluates every row whose validation is \033[1mREAD_ERROR\033[m
+
+         \033[1mrestore_*.tsv\033[m  report  (from restore_bad_signature.sh)
+            ->  evaluates every row whose status     is \033[1mWRITE_ERROR\033[m
 
    This script changes NOTHING. It never decrypts a file, never
    touches 'encryption_skip_signature_check', and never writes
    anywhere except its own report file. It only:
 
-      1. Reads a chosen recovery_*.tsv report (produced by
-         recover_bad_signature.sh) and picks out every row whose
-         validation is READ_ERROR and whose detail text matches one of
-         the two known key-material error signatures above.
+      1. Reads the chosen report and picks out the matching rows:
+
+            - from a \033[1mrecovery_*.tsv\033[m report: every row whose
+              validation is \033[1mREAD_ERROR\033[m
+            - from a \033[1mrestore_*.tsv\033[m report: every row whose
+              status is \033[1mWRITE_ERROR\033[m
+
+         ...and, in both cases, whose detail text matches one of the
+         two known key-material error signatures above.
       2. For each such file, resolves - via Nextcloud's normal,
          read-only Files API (\$node->getOwner(), \$folder->getById())
          - who currently owns the file, i.e. whether the affected
@@ -405,8 +418,11 @@ if $terminal ; then
    Nextcloud storage and never touches 'encryption_skip_signature_check'.
    It only inspects, on disk and via the normal Files API, whether the
    expected encryption key files are present for accounts/files that
-   recover_bad_signature.sh could not read (READ_ERROR, not 'Bad
-   Signature').\033[m"
+   recover_bad_signature.sh or restore_bad_signature.sh could not
+   process (not 'Bad Signature').\033[m"
+   echo ""
+   echo -e "   \033[1mrecovery_*.tsv\033[m report  ->  evaluates \033[1mREAD_ERROR\033[m rows"
+   echo -e "   \033[1mrestore_*.tsv\033[m  report  ->  evaluates \033[1mWRITE_ERROR\033[m rows"
    echo -e "\033[32m-----\033[m"
 fi