`<filesystem>`: `remove()` does not correctly set the `error_code` when file does not exist

[mntt-SSE]

Describe the bug

It seems that the error_code version of std::filesystem::remove() fails to report the reason why a file couldn't be removed when the file doesn't exist.

Command-line test case

C:\Users\mntt\test>type repro.cpp
#include <filesystem>
#include <iostream>

int main()
{
    std::error_code errorCode;
    if (!std::filesystem::remove("file_that_does_not_exist", errorCode))
    {
        std::cout << "File could not be removed because " << errorCode.message();
    }
}

C:\Users\mntt\test>cl /EHsc /std:c++latest repro.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34120 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

/std:c++latest is provided as a preview of language features from the latest C++
working draft, and we're eager to hear about bugs and suggestions for improvements.
However, note that these features are provided as-is without support, and subject
to changes or removal as the working draft evolves. See
https://go.microsoft.com/fwlink/?linkid=2045807 for details.

repro.cpp
Microsoft (R) Incremental Linker Version 14.41.34120.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:repro.exe
repro.obj

C:\Users\mntt\test>repro.exe
File could not be removed because unknown error

Expected behavior

repro.exe outputs that the file could not be deleted because it does not exist.

STL version

Microsoft Visual Studio Professional 2022 (64-bit) - Current
Version 17.11.2

Additional context

I asked a question about this on StackOverflow, and got the following comment:

I tried this code on VS2022 Win10 and it looks like it's an implementation problem. If you call GetLastError inside the if then it's set correctly to 2 ERROR_FILE_NOT_FOUND as per Microsoft's documentation. Seems the implementation of __std_fs_remove doesn't correctly populate the error with the last error code set by DeleteFileW If you try the following code, then you get the expected message: auto err = GetLastError(); errorCode = std::error_code(err, std::system_category()); std::cout << "Could not delete file because " << errorCode.message() << " " << err;

So tl;dr, this code does give the expected behavior:

#include <filesystem>
#include <iostream>
#include <Windows.h>

int main()
{
    std::error_code errorCode;
    if (!std::filesystem::remove("file_that_does_not_exist", errorCode))
    {
        auto err = GetLastError();
        errorCode = std::error_code(err, std::generic_category());
        std::cout << "Could not delete file because " << errorCode.message();
    }
}

C:\Users\mntt\test>repro.exe
Could not delete file because no such file or directory

[cpplearner]

This is by design. The C++ standard requires std::filesystem::remove to return false if the file did not exist ([fs.op.remove]/3), and MSVC STL does not consider this condition as an error.

[mntt-SSE]

There is another part of that condition:

Returns: false if p did not exist, otherwise true. The signature with argument ec returns false if an error occurs.

In my case I'm using the ec signature, so the second sentence should apply. If the file not existing is not an error, shouldn't that signature then return true in that case?

EDIT: I guess it could be interpreted as that the ec signature will return false both for errors and for non-existing files. And the way to see if a file does not exist is to check for the "false" return value and that there isn't an error. It seems pretty unintuitive to me, but I guess that's on the standard (or on me)!

[CaseyCarter]

The weirdness is because some people consider it to be an error if they try to remove a file that doesn't exist ("You can't remove something that isn't there!"), and some people consider it to be success ("I want there to be no file named meow, and there's no file named meow!"). Poor remove is unavoidably going to confuse some of the people some of the time, but it tries to serve both use cases by returning true if the file existed and was removed, and false - possibly with an error indication if an error interfered with removal - if no file was removed.

We're trying to come up with an improved phrasing at cplusplus/draft#7387, but it's not going great.

[mntt-SSE]

@CaseyCarter Thank you for your explanation, it makes a bit of sense now! Honestly, I think just adding an "also" to the second sentence would make it a lot less ambiguous: "The signature with argument ec also returns false if an error occurs."

[CaseyCarter]

We landed on:

Returns: true if a file p has been removed and false otherwise. [Note: Absence of a file p is not an error.-end note]

which I think is clearer despite being a bit less explicit. Thanks for the report!