> Alan McDonald wrote:
> >>Hi Set,
> >>
> >>
> >>>I think we experienced the same thing, only from one Windows server to
> >>>another Windows server. Though this was just a table I'd used once and
> >>>forgotten to delete, so we simply deleted it and made a new backup (or
> >>>rather, thinking about it - I think Aage created an empty file with
> >>>the name in question and successfully made a restore). I didn't even
> >>>think enough about it to consider the unlikely to have happened - that
> >>>we had encountered a new Firebird bug in a stable version...
> >>
> >>Well, the "bug" thing can be discussed, but obviously, this simply will
> >>never work when converting from one platform to another which uses
> >>a different path/file notation.
> >>
> >>
> >>>Just a note to tell that the problem may not be limited to
> >>>Linux->Windows.
> >>
> >>Windows to Linux as well, I guess :-)
> >>
> >>
> >>>Though it may be a bug that only bite people chewing
> >>>Bamsemums.
> >>
> >>I doubt it ... haven't been chewing those in a long time now :-(
> >>
> >>With regards,
> >>
> >>Martijn Tonies
> >
> >
> > and you know it's been like that for a long long time. Even when I used
> > external tables in version 4, I had this problem. I always had
> to place the
> > external file BEFORE I restored. And yes it was OK for WIN to
> WIN resotre
> > but would never have worked for WIN to Linux or versa. You need
> to disengage
> > the external table first, before backup.
> > Alan
> >
>
> Aren't there any switch to gbak to NOT process external files during
> restore ?
>
>
> Regards
> Boguslaw Brandys

only to incorporate them into the backup as if they are internal tables
Alan