mbdavid
Replace Mutex name hashing with URI escaping (Fix #2543)
Shared mode uses a named Mutex to avoid multiple processes reading/writing at the same time. LiteDB names the Mutex to contain the absolute file path of the database. But Mutex names have to be valid file paths, so this would cause an invalid file path like:
Global\c:\users\user\documents\github\litedb\litedb.tests\bin\debug\net8\demo.db.Mutex
So instead, currently it hashes the file path using SHA1 to turn it into the following:
Global\0a1ab52c4b3f3d01730f61b59e7891bc029ab372.Mutex
However, this is a hacky solution in my opinion. Someone experienced exceptions (#2543) caused when creating SHA1. This PR avoids the need to hash the path by using URL escaping:
Global\c%3A%5Cusers%5Cuser%5Cdocuments%5Cgithub%5Clitedb%5Clitedb.tests%5Cbin%5Cdebug%5Cnet8%5Cdemo.db.Mutex
Also, I changed it to use .ToLowerInvariant() instead of .ToLower() because Windows file paths are case insensitive even for non-ASCII characters (e.g. É and é).
This PR should fix #2543 since it removes hashing.
I should just mention that since this changes the name of the Mutex, shared mode won't lock correctly if you have two processes where one is using the current or older version of LiteDB and one is using a future LiteDB version.
Super hard to accept prs that are hard to test :/
I don't think so... It's pretty simple. If you like, I can write a test to ensure two connections can still be active at once.
Tbh i am unsure about this change. can we have a setting at userlevel that allows to set a flag for this? (Default this behaviour)
Hey, just following up on this. Would you be able to add a feature flag in the settings to allow reverting to the old behavior if needed? I believe this would address concerns around backward compatibility and make it easier to adopt the change. Let me know your thoughts!
Hey, just following up on this. Would you be able to add a feature flag in the settings to allow reverting to the old behavior if needed? I believe this would address concerns around backward compatibility and make it easier to adopt the change. Let me know your thoughts!
This would be a little frustrating, since you'd have to bring back the Sha1 function again. I don't think it's a big backwards compatibility break, because it's only there to avoid race conditions in shared mode (which is not a commonly used mode) and only when multiple processes are accessing the same database at once (and one of those processes is using an old LiteDB version). As long as LiteDB.Studio is also updated, I think this should be fine.