File-system ID may be duplicated among databases located on different volumes [CORE6323] #6564
Labels
affect-version: 2.1.7
affect-version: 2.5.0
affect-version: 2.5.1
affect-version: 2.5.2 Update 1
affect-version: 2.5.2
affect-version: 2.5.3 Update 1
affect-version: 2.5.3
affect-version: 2.5.4
affect-version: 2.5.5
affect-version: 2.5.6
affect-version: 2.5.7
affect-version: 2.5.8
affect-version: 2.5.9
affect-version: 3.0.0
affect-version: 3.0.1
affect-version: 3.0.2
affect-version: 3.0.3
affect-version: 3.0.4
affect-version: 3.0.5
affect-version: 4.0 Alpha 1
affect-version: 4.0 Beta 1
affect-version: 4.0 Beta 2
affect-version: 4.0 Initial
component: engine
fix-version: 3.0.6
fix-version: 4.0 RC 1
priority: major
qa: cannot be tested
type: bug
Submitted by: @dyemanov
Firebird uses file-system ID of the open database file to uniquely name its dependent shared memory files - lock table, event table, etc. File-system ID is retrieved using GetFileInformationByHandle() API and composed from the three fields (dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow) that are documented in MSDN as providing a unique combination:
https://docs.microsoft.com/ru-ru/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle
"You can compare the VolumeSerialNumber and FileIndex members returned in the BY_HANDLE_FILE_INFORMATION structure to determine if two paths map to the same target; for example, you can compare two file paths and determine if they map to the same directory."
The problem, however, is that Volume Serial Number (VSN) is not guaranteed to be unique. It's generated when then the volume is formatted and it's stored inside the volume's master boot record. But if the volume is cloned at the physical block level, or if a virtual (preformatted) drive is used, or if a volume snapshot (created by storage system like Dell EMC) is attached as a different logical drive, then VSN may duplicate an existing VSN. This may cause two different databases (located on different volumes) to share the same file-system ID thus sharing the same lock table, causing unexpected freezes and other undesired side-effects.
Commits: 9032a60 64bb799
The text was updated successfully, but these errors were encountered: