It depends a lot on what kind of duplications you are concerned with. For instance, a file-system copy would, presumably, have copied any "unique identifier" that may have been in the file, so it will no longer be unique. To detect that kind of duplication, I think you really need support at the VFS level.
It sounds like you believe that you have a file-system path to both databases. If that is the case, you can probably find a way to put a temporary "fingerprint" on one file that is unlikely to be "copied" to another file. For instance on windows (at least with a situation where LockFileEx() works as advertised) I believe you could: 1) Open the first file (read-only works on windows) 2) Select 129 byte addresses that are unlikely to be in use (somewhere near the peta-byte address. On windows the file doesn't have to be that big, and you wouldn't want to use this if it was. 3) Get an exclusive lock on one of those bytes to indicate that you are doing a fingerprint test. 4) Generate a GUID, and come up with a mapping from each bit of the guid to one of the other 128 bytes. 5) For each "set" bit of the GUID, gain an exclusive lock on the corresponding byte of the file. 6) For each "unset" bit of the GUID, gain a shared lock on the corresponding byte of the file. 7) Open the second file. 8) Attempt (non blocking) to gain exclusive and shared locks on the same 129 byte addresses in the second file. 9) If any attempt to gain an exclusive lock (2nd file) succeeds, the second file is different from the first file. 10) If any attempt to gain a shared lock (2nd file) succeeds where the first file has an exclusive lock, the files are different. 11) If any attempt to gain a shared lock (2nd file) fails, where the first file has a shared lock, the files are different. 12) Otherwise, the files are probably the same. 13) Release all of your locks. This could fail if somebody (possibly malicious) writes and uses a copy-lock-pattern tool. Something in the first six steps could fail if somebody else was using those bytes for some reason, but if the first six steps succeed, it seems unlikely that the remaining steps would "accidently" fail if the underlying file-system and GUID generation are robust. You could use fewer locks in a larger region to represent a guid (for instance, instead of mapping 128 GUID bits to 128 file bytes, map 16 GUID bytes to 16x256 file bytes). Regards, Bill -----Original Message----- From: ALBERT Aur?lien [mailto:aurelien.alb...@alyotech.fr] Sent: Thursday, September 24, 2015 4:42 AM To: 'sqlite-users at mailinglists.sqlite.org' Subject: [sqlite] Any database unique ID across multiple connections ? Hi, I'm using SQLite C API and my application use multiple databases, each database having multiple connections. I need to identify which connection use the same database as another connection. For the moment, I use the absolute database filename as an "unique database identifier", and I store this information with my "sqlite3*" connection handle. Is there any simpler/safer way to get a unique database identifier across multiple connections ? (for example, if one day I need the same about ":memory:" databases, bad things are gonna to happen) Maybe there is already a database identifier in the SQLite API and I missed it ? Thanks. ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. **************************************************************************************
