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.

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)

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.

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.

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.

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.

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

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)