Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nbackup uses aliases incorrectly [CORE1566] #1984

Closed
firebird-automations opened this issue Nov 6, 2007 · 11 comments
Closed

nbackup uses aliases incorrectly [CORE1566] #1984

firebird-automations opened this issue Nov 6, 2007 · 11 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Steffen Heil (sh-solutions)

Is related to CORE1390

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.

Commits: 8a07d31 e1d3bbc c255169

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @romansimakov

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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).

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is related to CORE1390 [ CORE1390 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ] => Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Target: 2.5.0 [ 10221 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 13381 ] => Firebird [ 14047 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Open [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants