Clarification on GetVolumeInformationW filesystem flags and NTFS maximum component length

Treat the successful GetVolumeInformationW result for the specified root as the runtime authority: test individual capability bits with masks, retain the full mask only as diagnostic state, and use the returned lpMaximumComponentLength instead of hard-coding 255.

1. Flag definitions and scope

The six values listed are the documented definitions:

They are consistent with the definitions documented for the relevant Windows headers and filesystem-attribute structure. GetVolumeInformationW receives their bitwise combination through lpFileSystemFlags; the documentation describes them as attributes or capabilities of the filesystem/volume associated with the specified root directory.^1^ ^2^

“Volume-level capabilities” is therefore reasonable shorthand, with two qualifications:

• The flags describe the volume/filesystem reached through the supplied root, not universal behavior inferred solely from the filesystem name.
• A capability bit does not necessarily describe every file or directory’s effective behavior. In particular, Windows supports per-directory case-sensitivity settings on NTFS, so FILE_CASE_SENSITIVE_SEARCH should not replace a query of the relevant directory when effective case-sensitive behavior matters.^3^

Also check the function’s return value before using any output. A zero return means not all requested information was retrieved; call GetLastError in that case.^1^

2. Selected subset versus complete bitmask

Calling those six checks a selected consistency subset is accurate as application terminology, provided it is made clear that:

• the subset is application-defined, not a Windows API category;
• it is not a complete enumeration of filesystem capabilities;
• each property is tested independently with bitwise AND;
• other set bits must not be interpreted as failures merely because they are outside the subset.

Windows defines many additional flags, including support for sparse files, compression, encryption, transactions, integrity streams, and USN journals.^1^ The lower-level filesystem attribute contract also says unrecognized flag values can be present and must be ignored.^4^

Consequently, comparing the entire mask for equality is suitable for recording or detecting any observed change, but it is brittle as a compatibility test:

• a newer Windows or filesystem implementation can introduce another bit;
• a volume-state bit, such as read-only status, can change;
• an exact-mask mismatch does not identify which capability relevant to the application changed.

Prefer comparing only the required subset for compatibility while preserving the complete value for logging:

constexpr DWORD requiredMask =
    FILE_CASE_PRESERVED_NAMES |
    FILE_UNICODE_ON_DISK |
    FILE_PERSISTENT_ACLS |
    FILE_SUPPORTS_REPARSE_POINTS |
    FILE_SUPPORTS_HARD_LINKS;

DWORD maxComponent = 0;
DWORD flags = 0;

if (!GetVolumeInformationW(root, nullptr, 0, nullptr,
                           &maxComponent, &flags, nullptr, 0)) {
    return HRESULT_FROM_WIN32(GetLastError());
}

bool hasRequiredCapabilities = (flags & requiredMask) == requiredMask;
DWORD observedFullMask = flags; // Preserve for diagnostics or change detection.

Include FILE_CASE_SENSITIVE_SEARCH in requiredMask only if filesystem-level support—not the effective state of a particular directory—is the intended condition.

3. NTFS component length

The three descriptions are compatible:

• The filesystem comparison documents NTFS’s maximum filename length as 255 Unicode characters and limits each path component to no more than 255 characters.^5^
• The path-length documentation says each component is limited to the value returned by GetVolumeInformation, which is commonly 255.^6^
• GetVolumeInformationW defines a component as the portion between backslashes and returns its supported maximum through lpMaximumComponentLength.^1^
• The lower-level attribute contract constrains the reported maximum to a positive value no greater than 255.^4^

Therefore, 255 is the documented NTFS limit, while the successfully returned value is the correct operational limit for the specific target volume. Do not infer the usable value merely from lpFileSystemNameBuffer == L"NTFS" or assume 255 for every target.

Finally, component length and total path length are separate constraints. A component can satisfy lpMaximumComponentLength while the complete path still exceeds the limit accepted by the particular API or application configuration.^6^

References

1. GetVolumeInformationW function (fileapi.h)
2. FILE_FS_ATTRIBUTE_INFORMATION structure (ntifs.h)
3. Adjust case sensitivity
4. 2.5.1 FileFsAttributeInformation
5. File System Functionality Comparison
6. Maximum Path Length Limitation