Send custom information through Windows FileSystem Attributes

Before getting into the point, I'll give you an overview of what I want to do. Because I don't know if using Windows Filesystem attributes is the right option to do that.

I have two components in the system. One of them is a ShellExtension that put an OverlayIcon when some condition is satisfied, and the other component is a Filesystem driver which provide information to Windows ( and therefore to the ShellExtension )

The FileSystem, using the name of the file make a network request to a remote server and depending on the result of this request, the overlay icon should appear or not.

The straightforward solution is to repeat the request from the OverlayIcon side, but this is not desirable. In the FileSystem side I have the request result, but I need to send it to the Overlay.

The first solution that came to my mind was use the Windows FileSystem attributes. I mean, in the Filesystem driver I will put a aparently-not-used attrubute ( for example 0x1000000 that appears not to be used according to MSDN ), and recover this information in the OverlayIcon, given that the explorer sends to the Shell Extension the file attribute as a parameter of "IsMemberOf". That is, use the Windows File Attributes to codify information from the FileSystem side to the ShellExtension one.

This solution doesn't work, it seems that in some part of the flow, this attribute is removed. It makes sense because this attribute appears not to be valid. If I replace the attribute value to one like HIDDEN, it works perfectly.

The obvious solution ( but it has more work to do ) is to use some IPC Mechanism.

But as I am on the both sides of the game It would be better 开发者_C百科if I could use the Windows Filesystem information.

What do you suggest?

Thank you!

---

Why so complex? There's a proper interface for this. Call GetFileInformationByHandleEx(FileRemoteProtocolInfo) to get a FILE_REMOTE_PROTOCOL_INFO. Put your protocol-specific data in ProtocolSpecificReserved. That's 64 bytes big.

The closest alternative to your current idea which might work would be to use FILE_ATTRIBUTE_REPARSE_POINT. If you use this, you can put a tag in WIN32_FIND_DATA::dwReserved0. This won't clash with other tags, as these tags are Microsoft-allocated.

http://msdn.microsoft.com/en-us/library/aa365511(VS.85).aspx

There are more places to squirrel your data away. You might consider using the lowest bit of the creation filetime. Do you really need 100 ns resolution, or is 200 ns good enough? Could you store it in BY_HANDLE_FILE_INFORMATION::nFileIndexHigh somehow?

---

You could store info in NTFS Alternate Data Streams