sumatrapdfreader
File parent directory can't be renamed after closing document tab.
SumatraPDF version
- Version 3.6.x pre-release
- This issue started AFTER pre-release build 16355, built on 2024-06-13, commit [2d5663c7bc0f1345bc4ad4a95c66edb7b05afb25]
- This issue started BEFORE pre-release build 16779, built on 2024-08-23, commit [bd354bcaaa12898a3beb539d2fdddcd7f1bef451].
- This issue exists in CURRENT pre-release build 17065, built on 2025-07-27, commit [cdadfde74471e9b06898e5c1e87edd98b4204597].
Describe the bug After closing an open document tab, and while SumtraPDF is still running due to other open document tabs, it retains exclusive use of the file system directory in which the document file itself is stored until such time as SumatraPDF is completely closed.
This issue prevents a separate running Windows app process from renaming the directory while SumatraPDF is still running even though SumatraPDF is no longer using the document file.
To Reproduce This can be reproduced with the Calibre e-book management app. Calibre organizes books using its unique file and directory naming system and hierarchy. It creates and names directories when books are imported and copied into the app, then it will rename a file and its parent directory when the title/author/publisher of a book are changed in the app.
Steps to reproduce the behavior:
- Make SumatraPDF your default app for .PDF files in Windows settings.
- Open any random document in SumatraPDF.
- In Calibre, open a book (SumatraPDF will open it in a 2nd document tab.)
- In SumatraPDF, close the document tab for the Calibre book.
- In Calibre, open "edit metadata" for the book.
- Rename the title of the book.
- Click OK to save metadata change.
- See error message produced by Calibre:
calibre, version 8.7.0
ERROR: Cannot open file or folder as it is in use: Could not change on-disk location of this book's files. The folder
"C:\Users\turbo\Books\Law Library\Byron Kosciusko Elliot\A Treatise on the Law of Evidence, (2069)"
is opened in another program, so calibre cannot access it. This is usually caused by leaving Windows explorer or a similar file manager open to a folder in the calibre library. Close Windows explorer and retry.
calibre 8.7 embedded-python: True
Windows-10-10.0.26200-SP0 Windows ('64bit', 'WindowsPE')
('Windows', '10', '10.0.26200')
Python 3.11.12
Windows: ('10', '10.0.26200', 'SP0', 'Multiprocessor Free')
Interface language: None
EXE path: C:\Program Files\Calibre2\calibre.exe
Traceback (most recent call last):
File "calibre\utils\copy_files.py", line 112, in _open_file
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:
'C:\\Users\\user\\Books\\Law Library\\Byron Kosciusko Elliot\\A Treatise on the Law of Evidence, (2069)'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "calibre\gui2\metadata\single.py", line 691, in accept
File "calibre\gui2\metadata\single.py", line 674, in apply_changes
File "calibre\gui2\metadata\basic_widgets.py", line 259, in commit
File "calibre\db\legacy.py", line 932, in func
File "calibre\db\cache.py", line 85, in call_func_with_lock
File "calibre\db\cache.py", line 1631, in set_field
File "calibre\db\backend.py", line 1893, in windows_check_if_files_in_use
File "calibre\utils\copy_files.py", line 252, in windows_check_if_files_in_use
File "calibre\utils\copy_files.py", line 136, in __enter__
File "calibre\utils\copy_files.py", line 132, in open_all_handles
File "calibre\utils\copy_files.py", line 123, in _open_file
File "calibre\utils\copy_files.py", line 112, in _open_file
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:
'C:\\Users\\user\\Books\\Law Library\\Byron Kosciusko Elliot\\A Treatise on the Law of Evidence, (2069)'
- Click OK to close the error message.
- Now, close SumatraPDF app and repeat step 7 ("Click OK to save metadata change.")
- Observe that no error message is produced.
Expected behavior It is expected that after closing a document tab in SumatraPDF, that it will no longer have exclusive use of the directory in which the document file is stored while it is still running due other open document tabs.
That is often a 3rd party Perl or Python complaint as For small (under32 MB) SumatraPDF does not lock files or their folders but Windows may.
For example I can be viewing a file and delete the folder containing it and SumatraPDF is none the wiser. It did not lock file or folder.
A secondary cause can be Explorer File Search or Preview when enabled by SumatraPDF install and thus the finger pointed at SumatraPDF dlls as enabler ! Often Windows does not know the file is closed permanently thus keeps the folder handle for reuse, until SumatraPDF is closed
Are you sure about that? Did you try to reproduce the issue using the versions I specified?
I just attempted to reproduce your example (using Windows, not Python) and Windows gave an error stating that It could not delete the directory because it was in use by another process.
@xtremeperf I suspect that file may be over 32 MB ? and then if PDF it will like many other PDF apps be locked for exclusive annotation (if required). and AFAIK for some other formats a similar rule would apply (even though there is now only PDF annotation) the example I tested in vanilla Windows was smaller and no explorer interference as I was not inside the folder when chopping the branch SumatraPDF had uploaded to memory. I can save the file to another folder but the point was it does not lock the source folder. Files over 32 MB cannot be deleted while viewing.
If you would reproduce the issue as described in the original post and if have any insight into what change(s) were made between build 16355 and 16779 that cause this issue, that would be very helpful.
I have not got all old versions and the only test that matters is does current pre-release 3.6.17065 do the unexpected ? I know from other forums Python file handling of folders can create such issues but not of just SumatraPDF calling. Current pre-release does hold file thus folder open over 32 MB and even when file closed and folder has been deleted unless the error was acknowledged and cleared windows will retain the wrong error message.!
Your first image shows the file is visibly open in SumatraPDF thus for a file (especially PDF in progress even if renaming), the folder cannot be renamed the file must be closed for Windows to recognise no folder/file handle is required to be retained against changes.
The only reason I took the first image was to show that I couldn't delete the parent directory while the file was open, because that was the example given in your first reply.
Regarding the 32 MB file size, I just reproduced the same issue using a PDF file under 1 MB.
Also, knowing the range of builds in which this issue first appeared could help track down the issue by deducing the code down to that which created the unexpected behavior using git diff or the like.
You described the issue as raising errors whilst python was running, and I know python irrespective of which app can go rogue in such conditions my test is python free so no interference. Having said that other factors can also have a bearing on how SumatraPDF related file handling is affected.
I am using 10 not 11 so cannot state your observations are unfounded, however, my own tests so far don't show unexpected file locking nor unexpected folder locking as a consequence.
I am not the developer who may be able to review past commit changes, but in general the ethos has been "only current release" can be varied. Hence my sole testing current pre-release behaviour in a hope to emulate what you describe and so far I cannot.
I suspect it is potentially either calibre or python triggered windows into not releasing a folder file handle thus suspect keep SumatraPDF open and close calibre or python the folder can be deleted
Here's a screenshot of SysInternals ProcessExplorer taken immediately after closing the tab. It shows the SumatraPDF process closing handle to the file (highlighed red) and leaving open handle to the parent directory (next line -- not highlighted red, thus not closed).
The issue reproduced with and without Calibre or Python running, and all build versions exhibited the same behavior that was described for each respective build in the original post.
Lets see so on its own (not a subprocess of Calibre) I see an exe a file and its folder are in progress
And on closure of that file the folder handle was not visibly flushed
However I can rename that folder no problem thus that handle should have disappeared or been renamed same as unlocked folder.
On reloading the new file path we see multiple new handles but one legacy one ? hmm
Closing the large file and open a small one there is no file handle just a folder one.