Hi @gerard76

I think this is actually expected behaviour and the solution be to mark these files as "to be ignored" by creating a file config/config.php like with content like this:

<?php
return array(
    'fileintegrity.ignore' => DI\add(array(
        'w.js',
        'w.php',
    ))
);

If someone else can confirm this is expected behaviour then this could be put in an FAQ.

I think the bug reported isn't that those files are shown, but that the check recommends deleting the original files instead of the "incorrect" symlinks.

If someone wants to fix this, they are welcome to submit a Pull Request.

👍 didn't notice there was a different message. For this particular case it would actually remove those files by adding the config but of course the actual bug remains which is the use of realpath in https://github.com/matomo-org/matomo/blob/4.0.0-b2/core/FileIntegrity.php#L75

Hi @gerard76 Instead of using symlinks, may I suggest you to use aliasing instead? This way you won't need any symlinks and you should be able to achieve what you want.

Sure you may. I have no problems with the symlinks though. Just reporting a bug.

I ran into this issue today and, indeed, it led to my inadvertently deleting a critical matomo source file. As @tsteur mentioned above the issue is caused because the paths are passed through realpath before being presented to the user. I think that a fine solution is to remove the realpath calls, because the paths, all being returned ultimately from glob calls, should be sufficiently canonical to make sense to the user, and to be executable on the command line. Can anybody think of a scenario where not calling realpath would be problematic? I'm going to submit a PR that removes these.

Tracing the history of the realpath calls, they go back to c8797e6, associated with #11123. Maybe @mattab can comment on whether there was a particular concern when the realpath calls were originally used.

If anybody is anxious about removing the realpath calls another option might be to run a final check before presenting a path to the user, to ensure it's not actually a path that IS part of the manifest. But with this approach the integrity checker would neglect to show the user the unexpected symlink file in the directory.