dotlockfile(1) swallows EPERM errors on lockfile removal

[strugee]

Testcase:

$ ./dotlockfile foo.lock sudo chattr +i foo.lock
$ echo $?
0
$ file foo.lock
foo.lock: ASCII text
$ rm foo.lock
rm: cannot remove 'foo.lock': Operation not permitted

[miquels]

Yes, but what else could it do? The lock succeeded, the command was run. The lockfile was left laying around, but that is a problem for the next time it runs. But, I do agree that if it then detects that the lockfile is stale but fails to remove it, it should print an error and exit with an appropriate status.

[miquels]

I've added 60cf79a so that we can at least fail fast, and detect internally that this was not just "can't lock". dotlockfile should really output warnings/errors if it cannot create a lock because of these sort of errors. However, I hope that I can release a new version that will make it into debian before the freeze, and that is too big of a change - will have to be done later this year.