[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Restoring a database under Debian

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Restoring a database under Debian
Date: Wed, 14 Jan 2015 19:18:44 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jan 14, 2015 at 05:53:51PM +0100, Karsten Hilbert wrote:

> > >   cp: cannot stat `backup-gnumed_v19-2015-01-12-09-59-25.tar': No such 
> > > file or directory
> > 
> > hmm … is it a
> > path problem?
> It is, but differently than you think :-)  I'll tell you the
> details as soon as time allows.

So, here's the explanation:

I noticed that the output of your restore

>       ==> Setting up workspace ... 
> Users/djb/gnumed/gm-restore-2015-01-13-10-27-04
>        ==> Creating copy of backup file …
>       cp: directory Users/djb/gnumed/gm-restore-2015-01-13-10-27-04 does not 
> exist

did not show a / at the beginning of the workspace path.
Going back to your config file that's because it was
configured that way:

>       ==> Reading configuration …

> # set this to a writable directory on a drive where
> # there is plenty of disk space available
> # WORK_DIR_BASE="${HOME}/gnumed"
> WORK_DIR_BASE="Users/djb/gnumed"

I should assume this came about when you set up this file to
match your environment. However, "Users/djb/gnumed" is a
relative path which leads to the restore script doing the

        echo "==> Setting up workspace ..."
        TS=`date +%Y-%m-%d-%H-%M-%S`
        echo "    ${WORK_DIR}"

create a temporary dir:

        mkdir -p ${WORK_DIR}

(which is, however, relative to the current dir because
$WORK_DIR_BASE is relative...)

        if test $? -ne 0 ; then
                echo "    ERROR: Cannot create workspace. Aborting."
                exit 1
        chmod +rx ${WORK_DIR}

then change into that directory (which works whether relative
or absolute):

        cd ${WORK_DIR}

        echo "==> Creating copy of backup file ..."

and *then* copy the backup to the work dir (which will fail
because it would apply the relative path to the work dir it
just changed into _again_):

        cp -v ${BACKUP} ${WORK_DIR}

Had $WORK_DIR been absolute (courtesy of $WORK_DIR_BASE being
absolute) this step would have worked.

        if test $? -ne 0 ; then
                echo "    ERROR: Cannot copy backup file. Aborting."
                echo "   "`ls -al ${BACKUP}`
                exit 1

I'll adjust the script to be more resilient. In the meantime
please re-run with the _full_ path to the backup file given
to the script.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]