#2499 NTFS file attribute letters in 7-zip

[Explorer]

This is a support request and not a bug report.

I wonder if 7-zip developers (Igor Pavlov and others) are interested in updating the NTFS attributes letters in 7-zip UI?

Because I maintain this answer in Super User and ntfs_attr.sh shell script, and I tried very hard in keeping the letters in sync with the (upstream) use in Windows Explorer and attrib.exe in Windows. I would like to share the information so that you can save time figuring out yourselves.

I've seen the "CPP/7zip/UI/Common/PropIDUtils.cpp" in the 7-zip source code, and it seems like the list is slightly out of date, so I propose these:

• FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x400000) has been showing as letter 'M' in file explorer.
• FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL seems to be defined as 0x20000000 in various sources on the Web (so your code comments look inaccurate). There are articles like this claiming that the "B", "SMR Blob attribute" in attrib.exe corresponds to this bit, but I cannot confirm it personally by myself.
  This is the list of all attribute letters:
  "RHSvDAxNTpLCOIEv.x.PU.M......b.."
  Uppercase are the letters currently shown in File Explorer, and lowercase ones are either obsolete and unknown. And yes there are same letter assigned to two attributes.

(In ntfs_attr.sh I use a different list "rhsvdaxntplcoieV.X.PU.M......B.." as Unix/Linux systems favor using lowercase letters first.)

[Igor Pavlov]

Thanks.
FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL was another value in Windows Kit 10.0.16267.
But later it was changed:

#define FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL  0x00200000  // 10.0.16267.0
#define FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL  0x20000000  // 10.0.17134.0

[Igor Pavlov]

Another question about attributes.
If 32-bit program creates file in root folder C:\, virtual file is created in C:\, and 32-bit program sees file attribute of created file:

#define FILE_ATTRIBUTE_VIRTUAL 0x00010000 

but I can't run 32-bit explorer.exe to look what attribute is shown in Windows.
if I run

C:\Windows\SysWOW64\explorer.exe

it calls 64-bit explorer.exe instead.
Is there any way to look that attribute in Windows?

real file is placed to

C:\Users\user\AppData\Local\VirtualStore

but file has no FILE_ATTRIBUTE_VIRTUAL in that folder.

[Explorer]

Thanks Igor.

Now the information about the silent change to the (undocumented) FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL constant value is new to me. And I don't have Windows Kit to verify this myself.

When Microsoft introduced new NTFS file attribute bits, they have been doing this silently and I consider them being anti-competitive as well (such as "Pinned" and "Unpinned" attributes specifically designed for OneDrive before they documented them for other cloud storage solutions).

I do not know anything about FILE_ATTRIBUTE_VIRTUAL, except I know it was not present in Windows 7 or before. It probably doesn't display any letter in Windows 8 Explorer as far as I remember (can't test it at the moment).

[Anders]

Run 32-bit Notepad or any other application that has the standard Open/Save dialog. The calls made to IShellFolder by DefView should be the same as Explorer...

[Igor Pavlov]

32-bit NOTEPAD doesn't show virtual items by some reason.
But 32-bit 7-Zip / add to archive / Browse shows virtual items with V attribute character.
But I supposed that V is used for bit 15: FILE_ATTRIBUTE_INTEGRITY_STREAM (V - ReFS Win8/Win2012). I have no ReFS to check it.
So do we know how INTEGRITY_STREAM attribute is shown for ReFS?

[Explorer]

Is @Anders familiar with the APIs that show the Open or Save files dialog?

What I am asking is, whether we can reverse-enginner one of the Windows DLL and figure out the remaining letters without tempering with the file systems. Because years ago, I tested out almost every attribute letter that may display in Windows Explorer by creating files with such attribute using various tools (even with ntfs-3g on Linux).

While I suspect the attribute column shown in the Open file dialog is same as Explorer's. Microsoft didn't really document which letters are used for which attribute and (as far as I have observed) sometimes attribute letters change between Windows versions.

The Not Content Indexed attribute is the notable one: In Vista it's displayed as "N" while in Windows 7 and later it's "I" and became consistent with attrib.exe letter use.

Between Windows 7 and Windows 10, the attribute letters that would display were "RHSDAXNTPLCOIE". Bit 15 and above are never shown. (And yes, I discovered FILE_ATTRIBUTE_DEVICE would show as "X" partly by accident. I have never figured out bit 3 though (unused in NTFS; used to refer to Volume Label in FAT).)

Somehow in one revision of Windows 10, it changed "P" meaning to refer to Pinned instead and added additional letters like "UM". Unfortunately I lost my Windows 10 laptop and thus I cannot test at the moment.

[Anders]

In 8.0 the string is "RHSDAXNTPLCOIEV" but since this is not a direct mapping it's not that useful to know it. 0x10 and 0x8000 are not displayed by GetDetailsOf and the V (0x010000) can't be displayed because it only uses the lower 16 bits (if you ask propsys directly it will give you the V however).

Starting in some version of 10 (with "RHSDAXNTLCOIEVPUMM"), IShellFolder can use the full 32-bits. If you want to know the bit to character mappings, just ask propsys in a loop (U is FILE_ATTRIBUTE_UNPINNED).

[Explorer]

@Ander
1. Is your information accurate at all? Because attribute 0x10 should refer to "D for Directory" and should have been displayed already. Are you referring to 0x08 instead (the reserved attribute bit formerly used as Volume Label in FAT)?
2. A web search of the string "RHSDAXNTPLCOIEV" gave me this result:
https://www.win7dll.info/propsys_dll.html
The string was surely embedded in the file named propsys.dll. While I can confirm all other letters, the "V" letter is the only one I couldn't confirm personally. It could refer to either Integrity Stream (0x8000) or Virtual (0x10000).
3. Currently a Google search on "RHSDAXNTLCOIEVPUMM" returns nothing. But two "M"s, really? While one "M" refers to "RecallOnDataAccess" (0x400000), what does the other M do? Also, what is the DLL version that you extracted this string from?

[Anders]

1) 0x10 was probably 0x8, sorry, I guess I can't shift in my head.
2) It's Virtual
3) M is 0x00040000 and 0x00400000 on 10.0.21xxx (I don't remember the exact build number and I don't feel like booting that machine again to find out) and I don't know which dll, I called the API...

[Explorer]

@Anders

0x40000 is "RecallOnOpen" and is in the lower bit position than "Pinned" (0x80000) and "Unpinned" (0x100000). I don't believe the API would display the attribute bits out of order...

Do you have the license to share the test code that you called GetDetailsOf to figure out the attribute letters? That can help people to independently verify the attribute letters that were otherwise undocumented by Microsoft.

[Anders]

GetDetailsOf needs a PIDL with the actual attributes you care about (meaning, for the upper 16-bits at least, I need an actual file). PSFormatForDisplay is what I used to dump the full mapping.