Fix Crash on permission failure

[Febbe]

• replaced fs::equivalent with 2 more robust calls to fs::weakly_canonical
• catches an error on failure.

[Febbe]

will merge in 24h if pipeline succeeds and if there are no objections
@Technius @rolandlo

[Technius]

Can you elaborate on where this "permission failure" is coming from?

[rolandlo]

Will this fix #2823 (comment)?

[Febbe]

Will this fix #2823 (comment)?

Very likely. I still don't know when and why this happens. For me, it seems like a permission failure. But the error message (unsupported operation) was not very specific, and it occurred in 90% of all cases. So I just decided to use a similar approach which is a lot more safe, but a bit more expensive. Since it is not in a loop, this is fine.

[createyourpersonalaccount]

@Febbe maybe it has to do with SIP protection? https://support.apple.com/en-us/HT204899
Here's a github issue from a different project that may be related to what was happening: gulrak/filesystem#77

[Technius]

We actually use that library for file system handling on Mac, but we're too close to our next release to bump up a dependency version and risk regressions. I propose just having this band-aid fix for now and bumping the library version after we're done with the 1.1.0 release.

Edit: we are using the ghc::filesystem version that supposedly includes the fix for the linked issue.

[Febbe]

It's also a problem on linux mint 20(Ubuntu 20.04), dunno if this happens on mac.
So the gulrak impl is not the cause here.

std::filesystem::equivalent throws when one of both filepaths have the filestatus not_found, despite the fact, that std::filesystem::equivalent also compares the filestatus.

There is also a defect report in the documentation to that: https://cplusplus.github.io/LWG/issue2937

[gaperez64]

Will this fix #2823 (comment)?

Very likely. I still don't know when and why this happens. For me, it seems like a permission failure. But the error message (unsupported operation) was not very specific, and it occurred in 90% of all cases. So I just decided to use a similar approach which is a lot more safe, but a bit more expensive. Since it is not in a loop, this is fine.

I can confirm that with the change to fs::weakly_canonical I am unable to reproduce the error. To be precise, the following code does not give the error anymore:

#include <iostream>
#include <cstdint>
#include <filesystem>
#include <cassert>

namespace fs = std::filesystem;

int main(int argc, char* argv[])
{
    assert(argc >= 3); 
    // hard link equivalency
    fs::path p1 = argv[1];
    fs::path p2 = argv[2];
    // if (fs::equivalent(p1, p2)) {
    if (fs::weakly_canonical(p1) == fs::weakly_canonical(p2)) {
        std::cout << p1 << " is equivalent to " << p2 << '\n';
        return 1;
    } else {
        std::cout << p1 << " is NOT equivalent to " << p2 << '\n';
        return 0;
    }   
}