phpDocumentor.phar 3.3.1 parses all files but does not generate any doc

[dejudicibus]

Expected behavior

Produce documentation from source

Actual behavior

Nothing

Installation

a. I downloaded the latest phpDocumentor.phar and saved it in C:\PhpTools\bin
b. I created a phpdoc.cmd executable script and saved in C:\PhpTools:
@php C:\PhpTools\vendor\bin\phpDocumentor.phar %*
c. I added C:\PhpTools to PATH System Environment Variable
d. I ran phpdoc --help on another folder to check if it works. It does!

Steps to reproduce the problem

1. I moved to D:#MyProject
2. I created D:#MyProject\doc for documentation and D:#MyProject\cache for cache
3. Source files are in D:#MyProject\src
4. I created phpdoc.xml as follows

<?xml version="1.0" encoding="UTF-8" ?>
<phpdocumentor
        configVersion="3"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="https://www.phpdoc.org"
        xsi:noNamespaceSchemaLocation="https://docs.phpdoc.org/latest/phpdoc.xsd"
>
    <paths>
        <output>doc</output>
        <cache>cache</cache>
    </paths>
    <version number="3.3.1">
        <api>
            <source dsn=".">
                <path>src</path>
            </source>
        </api>
    </version>
</phpdocumentor>

5. I launched phpdoc from D:#MyProject
6. I got

phpDocumentor v3.3.1

Parsing files
 59/59 [============================] 100%
Applying transformations (can take a while)
 21/21 [============================] 100%
All done in 1 seconds!

7. phpDocumentor created .phpdoc and .phpdoc\cache folders but NO documentation is saved in doc

Any idea why? What I did wrong? PS Of course, my PHP code contains a lot of phpDoc blocks.

Your environment

Windows 10 Professional Intl. ENG vers. 21H1
WampServer 3.2.7
PHP 7.4.9

[dejudicibus]

It looks like the problem is due to the path containing a folder starting by "#" (hash). phpDocumentor change #MyProject to %23MyProject and creates a %23MyProject folder in the filing system.

[mvriel]

D:# that is a new one for me :) What does that mean?

I have upgraded the League URI package yesterday; that introduced a seemingly similar issue for which I introduced a workaround. But this is a similar interesting bit, we may need to put some additional time in to solve these edge cases. I'm not sure we are able to resolve this issue quickly as the type of path resolving across multiple operating systems and virtual file systems is an interesting challenge :)

It would help us if you can describe how the # can be there so that we can write test case for that

[mvriel]

I have come across several issues with a similar pattern, I am going to merge duplicates into #3184.

This means that even though I am closing this issue, please know that we are working on it and using issue #3184 as reference