Re: calcsize locks /dev/null? Why?

The downside of testing with regard to locks is, depending on how the
timing works, an incorrect implementation may (almost) never fail.

Dustin

On Sun, Mar 24, 2019 at 9:30 AM Heiko Schlittermann <[email protected]> wrote:
>
> Dustin J. Mitchell <[email protected]> (So 24 Mär 2019 14:24:40 CET):
> > It looks like that was changed recently in client-src/calcsize.c
> >   https://github.com/zmanda/amanda/commit/2d5dcfecda760c08f9bff8d812fb45d9d0655fb1#diff-f89593c4478a9846176d4cdcb6b7e43a
> >
> > But that commit message is, sadly, totally useless.  The amflock(1,
> > ..) call comes from ancient, pre-git history.  So, I have no idea.
> > One thought might be to look in the users mailing list archives to see
> > if the commit mentioned above was fixing an error reported there.
>
> I built my own patch for testing in my own production environment
>
> --- a/client-src/calcsize.c
> +++ b/client-src/calcsize.c
> @@ -358,7 +358,14 @@
>      }
>      for(i = 0; i < ndumps; i++) {
>
> -       amflock(1, "size");
> +#define LOCKFILE "/run/lock/amanda.lck"
> +        int lockfd = open(LOCKFILE, O_WRONLY|O_CREAT, 0666);
> +        if (lockfd == -1) {
> +            error("can not open %s: %m", LOCKFILE);
> +            /*NOTREACHED*/
> +        }
> +
> +       amflock(lockfd, "size");
>
>         dbprintf("calcsize: %s %d SIZE %lld\n",
>                qamname, dumplevel[i],
> @@ -368,7 +375,8 @@
>                (long long)final_size(i, dirname));
>         fflush(stderr);
>
> -       amfunlock(1, "size");
> +       amfunlock(lockfd, "size");
> +        close(lockfd);
>      }
>      amfree(qamname);
>
> --
> Heiko