Subject | Re: [firebird-support] Re: GBAK - Restore Failure from 1.5 on Linux |
---|---|
Author | Helen Borrie |
Post date | 2007-01-05T05:29:01Z |
At 04:12 PM 5/01/2007, you wrote:
is inconsistent according to the documentation. The replace_database
switch is deprecated and the new behaviour is meant to be that it
cannot cause a database to be overwritten. For legacy support, it is
able to restore a backup to a new database; but only
-r[ecreate_database] O[VERWRITE] is capable of overwriting.
Therefore, if you can reproduce the behaviour of gbak -rep
overwriting a database, then Houston We Have A Problem.
./heLen
>Helen Borrie wrote:No, at present I can't test it. However, the behaviour you describe
> > Erk! It shouldn't, so your example (if repeatable) means gbak restore
> > is BROKEN and DANGEROUS. You had better post a high-priority bug
> > report to the Tracker !!!
> >
> > ./heLen
> >
>
>Helen,
>
>AFAIR -REP means replace to be explicit and does not confuse with -R
>witch was REPLACE and the people think it is RESTORE
>
>-REP was a shortchut the the option you said (-r[ecreate_database]
>O[VERWRITE])
>
>So from my poor memory, -R is restore and the file should not exists
>-REP is REPLACE and destroy the old file.
>
>Could you test to confirm the behaviour, and if you can confirm it I can
>post a message to fb-devel to ask for their opnion.
is inconsistent according to the documentation. The replace_database
switch is deprecated and the new behaviour is meant to be that it
cannot cause a database to be overwritten. For legacy support, it is
able to restore a backup to a new database; but only
-r[ecreate_database] O[VERWRITE] is capable of overwriting.
Therefore, if you can reproduce the behaviour of gbak -rep
overwriting a database, then Houston We Have A Problem.
./heLen