After calling fitz. open() to close, the number of file handles continues to increase, and the final display shows Too many open files

[black-zyp]

My data exists in the nas server, and there are thousands of PDFs that need to be read and converted into images. The PyMuPdf version is 1.20.2, and the Python version is 3.7. After the program runs for a period of time, the nas server shows that the number of handles to this program has been increasing, and the final error is: Too many open files. It should be that the handle to the file was opened through fitz and not closed, but I am sure that I have closed it using the close method, I am very confused. Is there any way to solve this problem?

[JorjMcKie]

This is a typical "Discussions" item. Let me transfer it first, so we can deal with it more effectively.

[JorjMcKie]

Please provide us with more detail about your configuration and your (maybe stripped down) script.
Among the questions I can initially think of is where do you store the generated images.
BTW, Python 3.7 has gone out of support by the Python Software Founbdation, and PyMuPDF will no longer provide wheels for it.

[black-zyp]

def pyMuPDF_fitz(pdfPath, imagePath):
# pdfDoc = fitz.open(pdfPath)
pdfDoc = fitz.Document(pdfPath)
file_name = os.path.basename(pdfPath).split('.')[0]
for pg in range(pdfDoc.page_count):
page = pdfDoc[pg]
rotate = int(0)
zoom_x = 5
zoom_y = 5
mat = fitz.Matrix(zoom_x, zoom_y).prerotate(rotate)
pix = page.get_pixmap(matrix=mat, alpha=False)
pix.writeIMG(imagePath + '/' + '%s%s.png' % (file_name, pg), format=1)
pdfDoc.close()

[JorjMcKie]

If this is the failing script, then you cannot be running PyMuPDF 1.20.x, but a much earlier version. I even cannot remember when Pixmap.writeIMG() ever was supported.
In versions earlier then 1.20.x there indeed was an issue (#1417) around too many open file handles.

As an aside, please use Github "slash commands" feature to show source code. The above snippet was short, but longer code pieces cannot be reviewed properly when entered as normal text.

[black-zyp]

Thank you for your reply. Now I need to wait for the NAS server to restart and try lowering the PyMuPdf version. By the way, how do Python and PyMuPdf versions match to be more stable?

[JorjMcKie]

Did not understand your last comment: lowering the PyMuPDF version? Shouldn't you upgrade PyMuPDF (and Python)?

Otherwise:

1. We always support the full set of Python versions that actively maintained by the Python Software Foundation (PSF). New versions, like the coming Python 3.12, are supported as soon as they are generally available. So Python 3.12.0 will be supported shortly after official availability in early October. PyMuPDF so far has not been dependent on a specific version ... except in the sense of making use of recent language capabilities like for example the use of "/" and "*" in function call patterns or certain functions in Python's C-interface.
2. About two years ago, there has been a major renaming effort, which removed camelCase names and converted them to their snake_case versions. This was a one-time effort. We were providing deprecation warnings for extended use of names, plus there is a utility for renaming old scripts plus you can still activate old names if neither of this is possible for you. Your mentioned Pixmap method writeIMG however was not even supported at the time when we started that renaming.

Does any of the above match or answer your question?

[black-zyp]

Okay, I already know how to do it. Thank you for your reply and wish you a happy life!

[JorjMcKie]

Okay, I already know how to do it. Thank you for your reply and wish you a happy life!

Thank you and same to you!
Please never hesitate to ask questions here on the "Discussions" tab or connect to us and to other users on the public Discord channel https://discord.com/channels/770681584617652264/983871937711341618.
If you suspect an issue, please enter it in the "Issues" tab, providing all required information. Enhancement requests also should be entered there.