1.18.7 cannot open pathlib.Path from subdir

[cbm755]

@JorjMcKie what do you make of this? It started in 1.18.7:

>>> from pathlib import Path
>>> f = Path("specAndDatabase") / "input.pdf"   # short name
>>> fitz.open(f)                                                                                                                                                                
Document('input.pdf')

So far so good, try again with longer filename:

>>> f = Path("specAndDatabase") / "input12345678.pdf"    # long filename                                                                                                                 
>>> fitz.open(f)                                                                                                                                                                
mupdf: cannot open input12345678.pdf: No such file or directory
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-37-7a249489c678> in <module>
----> 1 fitz.open(f)

~/.local/lib/python3.9/site-packages/fitz/fitz.py in __init__(self, filename, stream, filetype, rect, width, height, fontsize)
   3634         _fitz.Document_swiginit(
   3635             self,
-> 3636             _fitz.new_Document(
   3637                 filename, stream, filetype, rect, width, height, fontsize
   3638             ),

RuntimeError: cannot open input12345678.pdf: No such file or directory

Without the Path, it works fine:

>>> f = "specAndDatabase/input12345678.pdf"                                                                                                                                     
>>> fitz.open(f)                                                                                                                                                                
Document('specAndDatabase/input12345678.pdf')

It looks (from the error message) that it strips the directory from a path if the filename is too long (or maybe of the whole thing is too long, haven't dug deeper yet).

To Reproduce (mandatory)

Create pdf file named input.pdf and input12345678.pdf and put in directory as shown above. Follow steps above.

Your configuration (mandatory)

3.9.1 (default, Dec  8 2020, 00:00:00) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] 
 linux 
 
PyMuPDF 1.18.7: Python bindings for the MuPDF 1.18.0 library.
Version date: 2021-01-31 00:00:01.
Built for Python 3.9 on linux (64-bit).

[cbm755]

In fitz ctor:

        if not filename or type(filename) is str:
            pass
        elif hasattr(filename, "name"):
            filename = filename.name

So if filename is Path, that strips the preceding directories, and I bet I have an "input.pdf" in my CWD which explains why the first case worked! :-)

[JorjMcKie]

Damn ... sorry. I should have looked more closely into pathlib and take the absolute property instead.
Earlier it worked, because the str() function - which I used then - does exactly that. Sorry about that!
So as a workaround, please use str(path) for pathlibs ...

[cbm755]

Thanks!

I would think this will effect a lot of people: might be worth pushing a quick 1.18.8?

[cbm755]

Re: absolute or resolve not sure... I think I agree absolute but have not thought carefully.

Why do anything special? I gather you store the filename for later use in the class. But a string input is not made absolute, and presumably nothing terrible happens. So why do pathlib.Path need to be absolute?

Would this be reasonable? (Python 3 only)

if isinstance(filename, str) or isinstance(filename, os.PathLike):
    filename = Path(filename)

[JorjMcKie]

I would think this will effect a lot of people: might be worth pushing a quick 1.18.8?

Unfortunately yes - I will do that within 1 to 2 days.

Why do anything special? I gather you store the filename for later use in the class. But a string input is not made absolute, and presumably nothing terrible happens. So why do pathlib.Path need to be absolute?

The actual open of the file is not done by "me", but by MuPDF. And this guy of course needs a string that is sufficient to identify the file. It indeed does not need the absolute path (which would not harm either though).

All came up because I wanted to open document creation to Python file objects, and I was led astray by the fact that something created by open(path, "rb") has the full, unmodified "path" string in its name property - and pathlib.Path has not as you found out.
So the check will now be:

• string? -> ok, take it
• hasattr(f, "absolute")? -> take str(f) (do not use the absolute file path)
• hasattr(f, "name")? -> take f.name
• ValueError if none of the above

Python 2 has been dropped, so no special considerations here.

I need the actual filename - determined by one of the above - to judge whether I can allow incremental saves, because this can only happen to the original file of course.

[JorjMcKie]

Fixed in v1.18.8