New "pinned" attribute (since Windows 10 1709)

[MPB]

While going through the version 23 eval process, I happened to notice something odd...

With OneDrive, you can enable "Files On Demand" which only downloads files to your local sync folder as needed. It creates symlinks/junctions as needed for them all. TCC doesn't have any problems with that.

However, since the fall creators update (Win10 version 1709) Microsoft added a new file/directory attribute called "pinned" (P) that will mark a file or folder as *always* available offline, which (I think) downloads it always even if you have everything else marked as on demand.

From an explorer window, you can right click and select "always keep on this device" which will set that attribute, and you can see the "P" showing up in the attribute list if you display that column.

So I decided to head to TCC and see what the attribute looks like from the command line... I had marked my "Favorites" folder (which I have syncing with OneDrive) with that attribute, so I run:
attrib /d Favorites

Hmm... nothing there that looks like a "P", and furthermore, when I look back in the explorer window, the "P" disappeared and it's no longer set to "always keep on this device". By merely trying to look at the attribute list, it removed that new pinned attribute.

If I use the normal "attrib.exe" in the system32 directory I can set/remove that attribute no problem, and I guess if needed I can alias "attrib" to point to the standard Windows exe, but I thought I should definitely point that out since it's very much unexpected behavior.

Note that doing a "dir /t favorite*" doesn't show the attribute either, but at least it doesn't remove it, so that's good.

 

[Alpengreis]

IMHO always offline should be the +O NOT +P ... on the other side I read also in another forum:

Note that in the latest SDK headers there is FILE_ATTRIBUTE_PINNED. This refers to the "Always available on this device" setting for OneDrive files

Means +P ...

However: it's confusing, see (for example) here:
What do new Windows 8/10 attributes mean: No scrub file (X), Integrity (V), Pinned (P), Unpinned (U)

And yes, indeed, even an "easy" TCC attrib command does remove the CMD +P ...

 

[MPB]

I hadn't tried the "unpinned" until now... from Explorer you set it by right clicking a file/directory and choosing "free up space" which makes OneDrive delete the local copy, and sets the attributes "O" (offline) and "U" (unpinned).

Accessing the file by anything will make it re-sync locally and the "O" and "U" attributes disappear, as you would expect.

Using "attrib.exe +u testfile" will indeed clear the locally cached content (presumably...it may still be allocated for all I know), which led me to another difference in CMD and TCC...

For offline (non-cached) files, a directory listing shows the file size of an offline file in parentheses, like "(1159)" for the bytes. TCC sees the same offline file and just shows "1159", presumably because it's not seeing the "O" attribute indicating it's offline status?

Interestingly, you can't just set "+O" to make it offline - that does nothing. You have to +U "unpin" it which also adds +O, and then you can remove the "unpin" (un-unpin?) leaving just the "O" offline.

Kind of a confusing set of rules there, but I guess not too bad.

The difference in how CMD and TCC display the file size is what really caught my eye though since that's kind of a nice feature to see at a glance. Kind of like how TCC can show the actual allocated space, not just the size of the file itself, it's somewhat interesting.

 

[rconn]

I'm aware of the pinned / unpinned attributes; however I decided to wait before implementing them because :

1) Windows has a couple of other attributes which are required in combination with the pinned / unpinned, which Microsoft has failed to document.
2) Adding them is likely to break any batch files / aliases that rely on the current return format of @ATTRIB or DIR /T.
3) P has a conflict with the existing Sparse attribute
4) Nobody had asked for them until now.

 

[MPB]

That's understandable. I think the only problem I saw was that merely viewing attributes using the built-in "attrib" in TCC was resetting the pinned attribute (and may do the same for unpinned, sorry, I didn't think to check that).

Otherwise, using the Windows attrib.exe to do those other things is totally fine as far as I'm concerned.

It is unfortunate that Microsoft decided to re-use the letter "P" in this instance... you're right, that does lead to ambiguity and potential for breaking some small set of batch files that maybe used that for the "sparse" and would be surprised to find them "pinned" instead. I think they do have different numeric attribute IDs, so hey, that's something. :)

 

[Craig Barkhouse]

Just seeing this. A couple things. First, no other attributes are required in combination with pinned/unpinned. These can be manipulated independently on any file or directory. Second, P and U weren't previously used by attrib.exe, for sparse or anything else. So there was no conflict as far as Windows itself. Maybe there was a conflict as far as what TCC offers.

These flags aren't well documented but we are working on that. Unfortunately our documentation is behind in numerous areas. If you have any questions I can probably answer.

- Craig [MSFT]

 

[rconn]

Take Command / TCC v24 added support for pinned / unpinned in December 2018.