通过 Windows 文件系统属性发送自定义信息

发布于 2024-08-21 07:30:30 字数 842 浏览 2 评论 0原文

在进入正题之前,我先概述一下我想要做的事情。因为我不知道使用 Windows 文件系统属性是否是正确的选择。

我的系统中有两个组件。 其中一个是 ShellExtension,当满足某些条件时,它会放置一个 OverlayIcon,另一个组件是文件系统驱动程序,它向 Windows 提供信息(因此也向 ShellExtension 提供信息)

文件系统使用文件名向远程服务器发出网络请求,根据此请求的结果,是否应显示覆盖图标。

最简单的解决方案是重复来自以下位置的请求: OverlayIcon 一侧,但这是不可取的。在文件系统方面,我有请求结果,但我需要将其发送到覆盖层。

我想到的第一个解决方案是使用 Windows 文件系统属性。我的意思是,在文件系统驱动程序中,我将放置一个显然未使用的属性(例如 0x1000000 根据 MSDN 似乎未使用),并在 OverlayIcon 中恢复此信息,因为explorer 将文件属性作为“IsMemberOf”参数发送到 Shell 扩展。也就是说,使用 Windows 文件属性将信息从文件系统端编码到 ShellExtension 端。

这个解决方案不起作用,似乎在流程的某些部分,这个属性被删除了。这是有道理的,因为该属性似乎无效。如果我将属性值替换为 HIDDEN 之类的值,它就可以正常工作。

显而易见的解决方案(但还有更多工作要做)是使用某种 IPC 机制。

但由于我在游戏的双方,如果我能使用 Windows 文件系统信息会更好。

你有什么建议?

谢谢你!

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 if I could use the Windows Filesystem information.

What do you suggest?

Thank you!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

零度° 2024-08-28 07:30:30

为什么这么复杂?为此有一个合适的接口。调用 GetFileInformationByHandleEx(FileRemoteProtocolInfo) 来获取 FILE_REMOTE_PROTOCOL_INFO。将协议特定数据放入 ProtocolSpecificReserved 中。那是 64 字节大。

与您当前想法最接近的替代方案可能是使用FILE_ATTRIBUTE_REPARSE_POINT。如果你使用这个,你可以在WIN32_FIND_DATA::dwReserved0中放置一个标签。这不会与其他标签冲突,因为这些标签是 Microsoft 分配的。

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

还有更多地方可以存储您的数据。您可以考虑使用创建文件时间的最低位。您真的需要 100 ns 分辨率,还是 200 ns 就足够了?您能以某种方式将其存储在 BY_HANDLE_FILE_INFORMATION::nFileIndexHigh 中吗?

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?

世态炎凉 2024-08-28 07:30:30

您可以将信息存储在 NTFS 备用数据流

You could store info in NTFS Alternate Data Streams

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文