enhancement: open cookie stores (chrome/etc) locked by running browser processes

[dvgamerr]

chrome.CookieJar(store.FilePath()) is not working, when using chrome browser an show error is

open C:\Users\dvgamerr\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies: The process cannot access the file because it is being used by another process.

but working if close all chrome app

[srlehn]

The file is locked by Chrome.

We might be able to open it if we add FILE_SHARE_DELETE to the share mode.

TODO: fork syscall.Open() with sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)

[srlehn]

If you want to use kooky with a running chrome browser you can disable the lock feature in chrome with a --disable-features=LockProfileCookieDatabase flag when starting the browser.

---

https://github.com/yt-dlp/yt-dlp/issues/7271#issuecomment-1588197148 :

I don't have a solution but I have done some research that may be useful.

• the reason for using exclusive locking may be because of performance rather than to intentionally prevent external access

  • the LockProfileCookieDatabase feature results in SQLitePersistentCookieStore::enable_exclusive_access being set

  • this results in ?exclusive=true being added to the file URI passed to sqlite on Windows only source

  • sqlite then uses LockFileEx to lock the file see the EXCLUSIVE lock section of winLock()

I tried moving the Cookies database and creating a symlink and hardlink to it for chrome to use but LockFileEx follows the links. It's possible that if the database is placed on a filesystem that doesn't support locking (like an old version of samba) then the locking won't take effect but that isn't a very practical solution.

the shadow copy approach seems like a good way around the limitation on the yt-dlp side. I think admin will be required for any solution which makes many options available but most would be too invasive. One idea I had would be to create a separate tool that a user could use to start chrome and inject a DLL that makes LockFileEx do nothing.

The good news is that I don't think Linux will be affected because mandatory locking with fcntl is opt-in and disabled by default source (see Mandatory locking section). WSL should also be unaffected because LockFileEx hopefully can't be supported in WSL

[srlehn]

seems like its doable without admin rights (chrome restarts the process)

https://github.com/yt-dlp/yt-dlp/issues/7271#issuecomment-1791933997 :

And I guess I spoke too soon-ish. This project: thewh1teagle/rookie came up with a way to do it without admin. It cheats a bit, it actually kills the process in chrome that holds the lock to the file.. thus releasing the lock... but hey chrome, just restarts it when needed and it works out fine.

I've replicated it in a pure-python gist here: gist.github.com/csm10495/e89e660ffee0030e8ef410b793ad6a7e.. using that logic cookies can be fetched even while Chrome is running, without admin.

rust https://github.com/thewh1teagle/rookie/blob/02995bb/rookie-rs/src/winapi.rs#L63