Thanks for your response! Great to hear it doesn’t lock the file on Linux. Unfortunate it works not that way on Windows. I asked Claude how it’s possible that SumatraPDF can open a pdf without ‘locking’ the response:
Based on what’s in the SumatraPDF repo and forum/discussion history, here’s the trick — and it’s less “trick” and more a deliberate design choice made in two parts.
1. It opens the file handle in shared mode (not exclusive)
Most PDF readers (Adobe Reader/Acrobat in particular) call Windows’ CreateFile() with a restrictive share mode, which is why Dropbox, LaTeX recompiles, or a second process can’t touch the file while it’s open — Adobe Reader DC reserves exclusive write-access when it opens a file under Windows.
SumatraPDF instead opens the handle with sharing flags that permit other processes to read, write, and even delete/rename the file concurrently (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE in Win32 terms). Nothing on the OS side stops another process from overwriting the bytes on disk.
2. For smaller files, it reads the whole thing into memory and lets the handle go
This is the part that actually matters in practice, and it’s confirmed repeatedly by users and maintainers in the project’s own forum: SumatraPDF does not lock files under a size threshold (originally 10 MB, later raised to 32 MB in the 3.2+ pre-releases), so you can simply overwrite the file and it will refresh. A maintainer/community response frames this explicitly as intentional: it’s intentional and one of the reasons SumatraPDF is recommended in academic and publishing circles that PDFs up to 32 MB must not be locked, unlike Adobe products which need to be closed or killed to release the file.
Mechanically, this matches the classic technique used by editors/viewers designed for “hot reload” workflows (this is the same trick recommended as the standard workaround for Adobe’s locking, per the Adobe community thread): rather than keeping a live HANDLE/file mapping open into the PDF for the engine to stream from, the small file is slurped fully into a memory buffer at load time, the OS handle is closed (or never held with exclusive access to begin with), and rendering happens entirely from that in-memory copy. Since there’s no open handle asserting ownership of the file after the read completes, Windows has nothing to prevent LaTeX, Dropbox, git, or any other tool from truncating and rewriting the file on disk.
3. It watches the file for changes and reloads automatically
To make the “overwrite it externally” workflow actually useful (rather than just harmless), Sumatra pairs the non-locking read with a file watcher (src/utils/FileWatcher.cpp in the source tree), built on ReadDirectoryChangesW, that detects when the underlying file has changed on disk and reloads/re-renders it — which is exactly why LaTeX users can “compile → Sumatra auto-refreshes” without ever closing the viewer.
Why the size cutoff exists: for very large files, reading the whole thing into memory up front becomes expensive, so above the threshold Sumatra falls back to a more traditional streamed access pattern — and users on the forum confirm that above that size limit (e.g. 20 MB+ files in the versions tested), Windows does report the file as locked/in-use by SumatraPDF, just as with other readers. Even after closing individual tabs, some versions kept a lingering handle open on the folder due to caching/thumbnail-generation code paths, which the project treated as a bug and patched over several releases.
So there’s no filesystem-level exploit involved — it’s simply: read fully into RAM, don’t hold an exclusive/locking handle open, and use directory-change notifications to reload when the file underneath changes. That’s also precisely why it became the de facto standard PDF viewer for LaTeX/Markdown/Pandoc workflows on Windows.