Issue Details (XML | Word | Printable)

Key: CORE-1566
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Dmitry Yemanov
Reporter: Steffen Heil
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

nbackup uses aliases incorrectly

Created: 06/Nov/07 04:00 AM   Updated: 12/Nov/09 03:53 PM
Component/s: NBACKUP
Affects Version/s: 2.0.3
Fix Version/s: 2.5 Alpha 1

Time Tracking:
Not Specified

Issue Links:
Relate
 

Target: 2.5.0


 Description  « Hide
nbackup's documentation explicitly allows the use of aliases for backup.
However if aliases are used exclusively, that is with DatabaseAccess=None, nbackup will break.

nbackup still manages to get the right filename (propably attaching to the database using the alias) and is still able to access the database file (at least in my tests running as root), but seems to access the database later using the absolute file name, which then is rejected by the server.

nbackup should use the alias to connect. It would then even work with DatabaseAccess=None.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Roman Simakov added a comment - 06/Nov/07 07:47 AM
In isc_attach_database function of why.cpp the alias is resolved into real file name for local protocol. For remote access nbackup works fine.
nbackup -U sysdba -P masterkey -B 0 adb - faild
nbackup -U sysdba -P masterkey -B 0 localhost:adb - successful
It's right for gbak too and for other utils I think.

Must why.cpp in isc_attach_database resolve aliases?

Dmitry Yemanov added a comment - 06/Nov/07 08:11 AM - edited
AFAIU, this is a known issue for {XNET vs aliases vs DatabaseAccess = None}, it has nothing to do with nbackup itself.

Roman:

If why.cpp wouldn't resolve an alias, an extended pathname (<current_dir>\adb) would be passed to the engine and there won't be any chance to check an alias later. A proper solution requires changes in the remote protocol (op_attach should include both resolved and original pathnames).