Getting full file attributes for files managed by Microsoft OneDrive

Question

Microsoft OneDrive allows file to be stored either locally, remotely or in the both ways. This is determined by new file attributes which appeared in the Windows 10:

FILE_ATTRIBUTE_PINNED                0x00080000  
FILE_ATTRIBUTE_UNPINNED              0x00100000  
FILE_ATTRIBUTE_RECALL_ON_OPEN        0x00040000  
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 0x00400000

as well as some file attributes inherited from previous versions of Windows:

FILE_ATTRIBUTE_SPARSE_FILE           0x00000200
FILE_ATTRIBUTE_REPARSE_POINT         0x00000400  
FILE_ATTRIBUTE_OFFLINE               0x00001000

Problem is that I cannot find a way to retrieve these new file attributes via Win32 API or NT Native API. I've tried so far:

GetFileAttributes()
FindFirstFile()
NtQueryAttributesFile()

For OneDrive file which was set to be stored always remotely, all these methods return 0x00500020 whilst true attributes are 0x00501620 (REPARSE_POINT, SPARSE_FILE and OFFLINE are masked out). True file attributes can be retrieved using the following PowerShell command:

[Convert]::ToString( (Get-ItemProperty -Path 'C:\Users\username\OneDrive\test.txt').Attributes.Value__, 16 )

attrib.exe system command is also able to display some of these new OneDrive-related file attributes (O for offline, U for unpinned, P for pinned).

Is there a way to retrieve these file attributes in my software? Maybe I need to add something to the manifest?

In my experience those attributes are definitely returned by `GetFileAttributes()`. — Jonathan Potter, Feb 06 '19 at 21:22
To the best of my knowledge the "recall" attributes may _only_ be exposed when traversing the folder hierarchy. They seem to be synthesized by the file system driver or a filter driver in the same stack (filter driver is actually more likely). But I could be wrong, investigating the topic myself right now. I suppose your manifest will also have to declare compatibility with Windows 10 at least ... otherwise you'd also get different behavior in other APIs as well. — 0xC0000022L, Jun 25 '21 at 21:52
Also see [RtlIsCloudFilesPlaceholder](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtliscloudfilesplaceholder) and [RtlIsPartialPlaceholder](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlispartialplaceholder) ... they also got "recently" (I think 1709 or so?) exposed in ntdll.dll, not just inside ntoskrnl.exe ... — 0xC0000022L, Jun 25 '21 at 21:55

score 4 · Accepted Answer · answered Feb 15 '19 at 21:37

From MSDN RtlSetThreadPlaceholderCompatibilityMode

When placeholders are exposed, characteristics such as the presence of a reparse point, the sparse bit, and the offline bit are plainly visible through directory enumeration and other types of file information queries. When placeholders are disguised, these details are completely hidden, making the file look like a normal file.

Most Windows applications see exposed placeholders by default. For compatibility reasons, Windows may decide that certain applications see disguised placeholders by default.

I am guessing that Windows has placed your test program in some sort of compatibility mode and is therefore filtering the attributes.

RtlSetThreadPlaceholderCompatibilityMode

There are indeed shims which an admin could assign to programs or which sometimes MS seems to assign to enable this mode. Thanks for the pointer to the function. — 0xC0000022L, Jun 25 '21 at 21:49

Getting full file attributes for files managed by Microsoft OneDrive

1 Answers1

Linked