MSVC2015上的实验性C ++ 17文件系统：与权限不一致

Question

I'm trying to use the experimental <filesystem> library that should become part of C++17 (See draft technical spec N4100 ) on MSVC2015 (update 1).

I could manage to display full content of a directory recursively:

    using namespace std::tr2::sys;
    ...
    path dir = canonical(".");
    for (auto& p : recursive_directory_iterator(dir)) {
        if (is_regular_file(p))                
            cout << file_size(p);               
        perms pe = p.status().permissions();  // get authorisations
        cout <<"\t"<< (pe & perms::owner_read ? "r" : "-") // <== error should be allowed
            << (pe & perms::owner_write ? "w" : "-");
        cout <<"\t" << p << endl;     
    }

Problems and questions:

1. Bitwise & on the perms object: The compiler complains with a C2440 error about a missing conversion from perms to bool. But this should be allowed according to specs. Is this a bug or did I miss something ?

2. I cirumvented the issue by converting pe an unsigned. There I noted that the value is always 0xffff , for every files, including a file where I have intentionally withdrawn writing authorisations. Will a constant dummy value be returned for permissions on windows systematically or did I forget something to get the valid permissions ?

Answer 1

Update : What I said below about Windows' permissions is true, but for some reason even the FILE_ATTRIBUTE_READONLY bit doesn't appear to be working. I'll file a bug :)

As a workaround for now you can do a status() on the resulting path record, eg

#include <filesystem>
#include <iostream>
using namespace std;
using namespace std::tr2::sys;

int main() {
    path dir = canonical(".");
    for (auto& p : recursive_directory_iterator(dir)) {
        if (is_regular_file(p))
            cout << file_size(p);
        file_status stat = status(p); // Workaround bug in MSVC++2015
        perms pe = stat.permissions();  // get authorizations
        cout <<"\t"<< ((pe & perms::owner_read) != perms::none ? "r" : "-")
            << ((pe & perms::owner_write) != perms::none ? "w" : "-");
        cout <<"\t" << p << endl;
    }
}

on my system produces:

PS C:\Users\bion\Desktop\test> ..\fs.exe
68494859        r-      C:\Users\bion\Desktop\test\read-only.mp3
93805063        rw      C:\Users\bion\Desktop\test\read-write.mp3
PS C:\Users\bion\Desktop\test>

---

Bitwise & on the perms object: The compiler complains with a C2440 error about a missing conversion from perms to bool. But this should be allowed according to specs. Is this a bug or did I miss something ?

Bitwise & is supported through an overloaded operator& and should work fine. There is no conversion to bool. If you want a conversion to bool, the right way to do that is to compare with a constant declared by that enum class , eg:

if ((permsVar & perms::owner_read) != perms::none)

or with a direct-initialized instance of that enum class:

if ((permsVar & perms::owner_read) != perms{})

[bitmask.types] only says:

The value Y is set in the object X if the expression X & Y is nonzero.

not that there is some conversion from the literal 0 you can use to compare with the enum class .

I cirumvented the issue by converting pe an unsigned. There I noted that the value is always 0xffff, for every files, including a file where I have intentionally withdrawn writing authorisations. Will a constant dummy value be returned for permissions on windows systematically or did I forget something to get the valid permissions ?

Windows' permissions model really has no analogue to the Unix permissions model -- security descriptors do have owner and group owner values, but there's no generally accepted convention to map between Windows DACLs (which can express much finer-grained permission constructs than Unix permissions) and Unix permissions.

As a result, at present we just look for the readonly attribute, or for one specific set of attributes, and if it isn't that we "punt" and say that the permissions are unknown. If you want to be portable, you need to do something with the unknown constant.

        // FILE STATUS FUNCTIONS
_FS_DLL _File_type __CLRCALL_PURE_OR_CDECL _Stat(const TCHAR *_Fname, _Perms *_Pmode)
    {   // get file status
    WIN32_FILE_ATTRIBUTE_DATA _Data;

    if (TFUN(GetFileAttributesEx)(_Fname, GetFileExInfoStandard, &_Data))
        {   // get file type and return permissions
        // !!! Here's where we check
        if (_Pmode != 0)
            *_Pmode = _Data.dwFileAttributes & FILE_ATTRIBUTE_READONLY
                ? READONLY_PERMS : perms::all;
        return (_Map_mode(_Data.dwFileAttributes));
        }
    else
        {   // invalid, get error code
        // error mapping code omitted
        }
    }

What would you expect us to do with a security descriptor like:

O:BAG:SYD:PAI(A;;WD;;;WD)(A;;FA;;;S-1-5-21-2127521184-1604012920-1887927527-9342113)(A;;0x4;;;BA)

which says:

O:BA : The owner is BUILTIN\\ADMINISTRATORS .
G:SY : The group owner is NT AUTHORITY\\LOCAL SYSTEM . Note that the group is not generally used at all in Windows permissions and exists only for compatibility with Interix, in which case Interix is the only one reading or writing the security descriptor and as such can do whatever it wants. :)
D:PAI : The DACL is DACL_PROTECTED (doesn't inherit permissions from parents) and DACL_AUTO_INHERIT (participates in the normal permissions inheritance system; eg children of this filesystem object will inherit permissions from this)

• (A;;WD;;;WD) : Grant WRITE_DAC (permission to change the DACL part of the security descriptor) access to WORLD\\EVERYONE . Hmm, WRITE_DAC isn't read, write, or execute, so what would we do there?
• (A;;FA;;;S-1-5-21-2127521184-1604012920-1887927527-9342113) : Grant FILE_ALL_ACCESS to REDMOND\\bion . Note that I am not the owner, the group owner, or "others" so how would you map this?
• (A;;0x4;;;BA) Grant FILE_APPEND_DATA to BUILTIN\\ADMINISTRATORS . That's kind of like write, but doesn't allow you to change content already in the file...

(And I'm leaving out a bunch of stuff like Mandatory Access Control....)

I'm not saying that we couldn't try to do better at this mapping, but if you need to do nontrivial permissions work the <filesystem> TS can't really help you on systems that support access control lists.