powershell - How to Determine OneDrive or SharePoint Directory Using SHGetPropertyStoreFromParsingName - Stack Overflow

admin管理员组

文章数量:1391925

Question: I have been using PowerShell to check the Available Status of a file in OneDrive or SharePoint directories using Shell32.dll. Previously, the GetDetailsOf function returned Available Status at index 303. However, after updating to Windows 24H2, I noticed that the index for Available Status changed to 304, making 303 unreliable.

[powershell]
$folderPath = 'D:\aaa\test\OneDrive\TEST_FILES'
$fileName = 'test.txt'

$shell = New-Object -ComObject Shell.Application
$folder = $shell.Namespace($folderPath)

if ($folder -eq $null) {
    Write-Output "Folder not found: $folderPath"
    exit
}

$item = $folder.ParseName($fileName)

if ($item -eq $null) {
    Write-Output "File not found: $folderPath\$fileName"
    exit
}

for ($i = 0; $i -lt 400; $i++) {
    $name = $folder.GetDetailsOf($null, $i)
    $value = $folder.GetDetailsOf($item, $i)
    Write-Output "$i : $name → $value"
}

Since the index may change in future updates, I am looking for a more reliable method to determine whether a given directory belongs to OneDrive or SharePoint.

MFC/C++ Alternative Using SHGetPropertyStoreFromParsingName To find a more stable way, I examined properties retrieved from SHGetPropertyStoreFromParsingName. I discovered that OneDrive and SharePoint directories consistently return 14 for PKEY_FilePlaceholderStatus, while local directories return 6.

[MFC Code for Checking OneDrive/SharePoint Directories]
CString filePath;
m_edit.GetWindowText(filePath);

HRESULT hr = CoInitialize(nullptr);
if (FAILED(hr)) {
    std::wcerr << L"CoInitialize failed: " << std::hex << hr << std::endl;
    return;
}

IPropertyStore* pPropertyStore = nullptr;

hr = SHGetPropertyStoreFromParsingName(filePath, nullptr, GPS_DEFAULT,             IID_PPV_ARGS(&pPropertyStore));

if (SUCCEEDED(hr)) {
    PROPVARIANT propvar;
    PropVariantInit(&propvar);

    hr = pPropertyStore->GetValue(PKEY_FileOfflineAvailabilityStatus, &propvar);
    if (SUCCEEDED(hr) && propvar.vt == VT_UI4) {
        CString str;
        str.Format(L"OfflineAvailabilityStatus: %d", propvar.uintVal);
        AfxMessageBox(str);
    } else {
        std::wcerr << L"Failed to retrieve PKEY_FileOfflineAvailabilityStatus." <<     std::endl;
    }
    PropVariantClear(&propvar);

    hr = pPropertyStore->GetValue(PKEY_FilePlaceholderStatus, &propvar);
    if (SUCCEEDED(hr) && propvar.vt == VT_UI4) {
        CString str;
        str.Format(L"FilePlaceholderStatus: %d", propvar.uintVal);
        AfxMessageBox(str);
    } else {
        std::wcerr << L"Failed to retrieve PKEY_FilePlaceholderStatus." << std::endl;
    }
    PropVariantClear(&propvar);

    pPropertyStore->Release();
} else {
std::wcerr << L"SHGetPropertyStoreFromParsingName failed: " << std::hex << hr <<     std::endl;
}

CoUninitialize();

Questions: Is there any official documentation confirming that PKEY_FilePlaceholderStatus returns 14 for OneDrive/SharePoint directories and 6 for local directories? Is this a reliable approach that will remain consistent across future Windows updates? Are there alternative methods to identify OneDrive/SharePoint directories without depending on volatile PowerShell property indices (303, 304, etc.)? Any insights or suggestions would be greatly appreciated!

I initially used PowerShell to check the Available Status (GetDetailsOf with index 303). However, after updating to Windows 24H2, I noticed that the Available Status index changed to 304. Since this index might change again in future updates, I looked for a more stable alternative.

To solve this, I tested MFC/C++ with SHGetPropertyStoreFromParsingName. I found that:

OneDrive/SharePoint directories consistently return 14 for PKEY_FileOfflineAvailabilityStatus. Local directories return 6. I was expecting to find official documentation confirming that this behavior is stable across Windows versions. However, I couldn’t find any concrete references to support this observation.

I’m looking for confirmation that this approach is reliable, or if there’s a better way to detect OneDrive/SharePoint directories programmatically.

本文标签：