[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
following:
echo "==> Setting up workspace ..."
TS=`date +%Y-%m-%d-%H-%M-%S`
WORK_DIR="${WORK_DIR_BASE}/gm-restore-${TS}/"
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
fi
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
fi
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.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian,
Karsten Hilbert <=
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/14
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Busser, Jim, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/15
- Re: [Gnumed-devel] Restoring a database under Debian, Karsten Hilbert, 2015/01/15