ijp
lock file is not removed at guild update
Reported by Stis on freenode #guile
lock file is not removed at guild update.
A possible solution is to always rm the lock file if we are about to make a new database or supply a clean-lock argumend to guild.
backtrace:
stis@blackbone:~/stis/src/guildhall$ guild clean
Backtrace:
In ice-9/boot-9.scm:
157: 13 [catch #t #<catch-closure 12ee920> ...]
In unknown file:
?: 12 [apply-smob/1 #<catch-closure 12ee920>]
In ice-9/boot-9.scm:
63: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
414: 10 [eval # #]
In /home/stis/stis/src/guile/meta/guild:
68: 9 [main ("/home/stis/stis/src/guile/meta/guild" "clean")]
In scripts/clean.scm:
46: 8 [main]
In guildhall/cli.scm:
94: 7 [call-with-parsed-options #<directory (scripts clean) 13bfc60> () ...]
In guildhall/cli/db.scm:
71: 6 [#<procedure 1fd97e0 at guildhall/cli/db.scm:70:4 (args config)> () #]
In ice-9/boot-9.scm:
171: 5 [with-throw-handler r6rs:exception ...]
In guildhall/database.scm:
177: 4 [open-database # # # ...]
In ice-9/boot-9.scm:
102: 3 [#<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)> r6rs:exception ...]
In unknown file:
?: 2 [#<procedure 1fec4e0 (key . args)> r6rs:exception #]
In guildhall/cli/db.scm:
48: 1 [#<procedure 1fed0f0 at guildhall/cli/db.scm:47:4 (c)> #]
In ice-9/boot-9.scm:
106: 0 [#<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)> r6rs:exception ...]
ice-9/boot-9.scm:106:20: In procedure #<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: ERROR: R6RS exception:
1. &fatal-error
2. &message: "database locked: /home/stis/.local/var/lib/guildhall/"
The problem isn't so much that guild update doesn't remove the lock, but the command that ran before it didn't. If the commands were to ignore the lock willy-nilly, it would defeat the purpose of a lock in the first place.
Solution, as I see it, is to fix the commands so that locks get released if an exception is raised. If a lock is in place, you should get a nice error message. And maybe add a command for cleaning the lock explicitly, in case it all does go awry.
yes, the error should get more friendly treatment rather than throw all things plus backtracking directly. The same issue occurs when a package wasn't found in the repo.
The database lock issue occurs when I try ctrl+c when it works, maybe we can add a sigaction for SIGINT too. Besides, I patched 'fatal' procedure to display a friendly error message, without backtracking info, users will be frightened by these things.