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

FB server reports that DB file is used by another application on secondary attachment attempt through a symlink [CORE3558] #3914

Open
firebird-issue-importer opened this issue Jul 16, 2011 · 9 comments

Comments

@firebird-issue-importer

Submitted by: Manish Tripathi (mtripathi)

Votes: 1

When the second connection is attempted to the database that is already open by the server, using a different relative path (which contains symlinks), the server incorrectly reports that the file is being used by another process.

Example:
Absolute path to the database is "c:\db\application.fdb", first connection to this database is established successfully.
If we create a symbolic link to the directory "c:\db" and name it, for instance, "sdb", the path "c:\sdb\application.fdb" would point at the same database file. However, the server does not seem to be able to recognize this. I.e., when we try to establish the second connection to the same database using the path "c:\sdb\application.fdb", the server erroneously reports that the file is being used by another process.

Proposed resolution:
The server must resolve symlinks before comparing database paths. It appears that right now when comparing database paths, the server does not resolve symlinks which tricks the server into believing that different symbolic links represent different database paths, where in fact they link to the same database file.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 16, 2011

Commented by: Sean Leyne (seanleyne)

The current functionality is not an error, depending on the version (SuperServer, Classic, SuperServer) of the engine you are attempting to connect with.

Please confirm the version you are using.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Modified by: Manish Tripathi (mtripathi)

environment: MS Windows + NTFS => MS Windows + NTFS, SuperServer

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Commented by: Manish Tripathi (mtripathi)

We are attempting to connect with SuperServer.

I may not have been clear enough, if we try to connect to the database using absolute disk path ("c:\db\application.fdb" in the previous example) it works fine. The problem occurs only when secondary attachments are attempted with the path, which contains symbolic links and is different from the "c:\db\application.fdb", though refers to the same database (for instance "c:\sdb\application.fdb" , where "sdb" is a symbolic link to "c:\db" folder)

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Commented by: Sean Leyne (seanleyne)

Why are you connecting via multiple path/references?

It seems that you want the engine to solve your own inconsistent references? Have you looked at using database aliases?

Again, the current functionality is entirely as expected.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Commented by: Manish Tripathi (mtripathi)

Okay, never mind. Let's consider that closed.

On a side note, I wouldn't call symbolic link an inconsistent reference, but that's my own opinion which you are obviously not agreeing to, and that is fine. But even if we assume that symbolic links are to be viewed as "inconsistent references" I always thought that robust software is supposed to accept inconsistent input and behave consistently wherever possible. I guess I was wrong, sorry to be a bother.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Commented by: @dyemanov

I would concur that it's actually a bug, although a minor one. We have symbolic links properly expanded on POSIX, so one would expect the Windows version to behave the same way.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 17, 2011

Commented by: Manish Tripathi (mtripathi)

Thank you, Dmitry. That is exactly what my claim is. It is a bug, and it is a minor one.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 15, 2013

Commented by: Funta (funta)

I'd really love to see this fixed because I'm using NTFS symlinks and junctions a lot to switch my testing environment.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa964920%28v=vs.85%29.aspx

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 24, 2013

Commented by: Sean Leyne (seanleyne)

The link (GetVolumeInformationByHandleW function) provided does not relate to the issue at hand.

I think you meant to point to GetFinalPathNameByHandle function (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364962(v=vs.85).aspx) but unfortunately, that function is only supported in Windows version later than 2008 or Vista. (Unfortunately, there doesn't seem to be any other File API function which resolves reparse/symbolic links)

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

Successfully merging a pull request may close this issue.

None yet
1 participant