NTFS 备用数据流 - 好主意还是坏主意？
我想存储一些与应用程序相关的文件元数据，NTFS 备用数据流 (AltDS) 允许我将此元数据直接存储在文件上，而不是存储在单独的数据库中。
我只是觉得这不是一个好主意。我知道这仅适用于 NTFS，但至少如果用户将文件复制/移动到非 NTFS 驱动器，他们会收到来自 Windows 的警告（是的，是的，我知道没有人读取警告）-
而且，存储文件上的附加数据可能会变得非常浪费，因为即使我的应用程序被卸载，AltDS 仍然存在。就像十年前，人们在卸载程序后使用“注册表清理程序”从注册表中删除无用的条目，以使系统运行得更快（当清理程序清理得太多时，系统会变得不太稳定......）。
我只是想知道它们可以合理用来做什么？它们是否应该完全留给 Microsoft Apps 使用？或者是否存在某种通用策略哪些类型的应用程序可以使用它们（恶意软件除外）？
编辑：只是为了澄清我的想法是什么。我正处于为自己编写小型文档管理系统的早期阶段。因为我想自由地移动文件，所以我想在文件上存储元数据，这样如果我移动/重命名/修改它们，我的应用程序仍然可以识别它们。它可以是整个元数据，也可以只是与单独数据库配合使用的 GUID。
总结一下给出的要点：
优点：
- 元数据随文件一起移动，因此无需通过散列或文件名来识别它
- 适用于所有文件类型，甚至是无法在文件本身中存储任何数据的 .txt 文件
缺点：
- 仅适用于 NTFS这可能不是未来 Windows 版本中的默认文件系统
- 虽然如果 MS 不自动转换它们（如果它们将 WinFS 组合在一起），我会感到惊讶
- 我的应用程序被卸载，AltDS 仍然存在
- 隐私问题
- 脆弱
- 大多数 USB 记忆棒都是 FAT32。许多私有文件服务器都是Linux。从互联网下载文件应该只传输文件而不是流。简而言之：很容易失去它们。
I would like to store some Application-Related Metadata for Files, and NTFS Alternate Data Streams (AltDS) would allow me to store this metadata directly on the files rather than in a separate database.
I just don't feel like this is a good idea. I know that this only works on NTFS, but at least if the user copies/moves the files to a Non-NTFS drive they get a Warning from Windows (yeah, yeah, no one reads warnings, I know)-
But also, storing additional data on a file can become very wasteful, as the AltDS stay even if my Application is uninstalled. It's like a decade ago when people used "Registry Cleaners" to remove useless entries from the registry after uninstalling a program to make their system run faster (and less stable when the cleaner cleaned too much...).
I just wonder what they can be reasonably used for? Should they be completely left for Microsoft Apps to use? Or is there some sort of common policy what types of apps may use them (apart from malware)?
Edit: Just to clarify what my idea was. I'm in the early stages of writing a small document management system for myself. Because I want to have the freedom to move files around, I want to store metadata on the file so that if I move/rename/modify them, my app still recognizes them. It could either be the entire Metadata or just a GUID that works with a separate database.
To summarize the points given:
Pros:
- Metadata moves with the file, so no need to recognize it through hashing or filename
- Works with all FileTypes, even .txt files where it's impossible to store any data in the file itself
Cons:
- Only works on NTFS which may not be the default file system in future Windows Versions
- Although it would surprise me if MS doesn't automatically convert them if they ever get WinFS together
- AltDS remain even if my App is uninstalled
- Privacy concerns
- Fragile
- Most USB Sticks are FAT32. Many private file servers are Linux. Downloading a file from the internet should only transfer the file but not the streams. In short: It's rather easy to lose them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
另一个症结所在：备份软件。有些人会忽略它，有些人不会恢复它，有些人会支持它，但在没有你告诉的情况下不会做任何事情。
Another sticking point: Backup software. Some ignores it, some doesn't restore it, and some support it but don't do anything without you telling it to.
如果没有有关您存储的数据类型的更多信息，很难说。您似乎意识到了涉及它们使用的一些问题，所以我不确定我能提供多少帮助。不过，这是我对备用数据流的一般想法：
首先，正如您所指出的，AD 流仅适用于 NTFS。如果您有机会需要将此元数据存储在 FAT 文件系统上，则需要某种后备机制。现代 PC 可能具有 NTFS 格式的内部硬盘驱动器，但您遇到的大多数 USB 闪存驱动器仍然是 FAT 格式。如果您的用户将数据文件存储在闪存驱动器上，请记住这一点。
除此之外，我想不出任何技术原因来避免广告流，但我仍然对使用它们持谨慎态度。人们往往会对那些向他们“隐藏”数据的应用程序感到紧张，无论其意图如何。考虑一下索尼 rootkit 的惨败等等。我并不是说你的应用程序有那么糟糕，但人们（尤其是不太懂技术的人）可能无法区分其中的区别。尽管如此，我仍然允许它们对您的应用程序有有效的用途。当然，卸载后留下广告流的问题仍然是非常现实的。您可能需要考虑为运行卸载程序的人员提供运行程序来搜索其驱动器并清理任何剩余流的选项。
另外，请记住KISS 原则。使用 AD 流真的是有效解决应用程序元数据存储问题的最简单方法吗？如果是这样，也许 AD 流是一个好主意，但如果不是，我会认真考虑采取另一种方法。
It's hard to say without more information about the kind of data you're storing. You seem to be aware of some of the concerns involving their use, so I'm not sure how much I can help. Here's my general thoughts on alternate data streams, though:
First of all, as you've noted, AD streams only work on NTFS. If there's any chance you'll need to store this metadata on a FAT filesystem, you'll need some kind of fallback mechanism. Modern PCs will probably have NTFS-formatted internal hard drives, but most USB flash drives you encounter are still FAT-formatted. Keep that in mind if your users will be storing data files on flash drives.
Aside from that, I can't think of any technological reasons to avoid AD streams, but I'd still be wary of using them. People tend to be nervous about applications that "hide" data from them, regardless of the intent. Consider the Sony rootkit fiasco, and so on. I'm not saying your application is anywhere near as bad as that, but people (especially the less tech-savvy) may not make out the distinction. Still, I will allow that they might have a valid use for your application. The problem of leaving the AD streams behind after uninstallation is still very real, of course. You might want to consider giving people running the uninstaller the option of running a program to search their drive(s) and clean up any remaining streams.
Also, remember the KISS principle. Is the use of AD streams really the simplest way to effectively solve your application's metadata storage problem? If so, maybe AD streams are a good idea, but, if not, I'd seriously consider taking another approach.
我能想到一个不使用它们的好理由，那就是他们的“使用方法”指南：
现在...按照这种措辞方式，我想，技术上你是安全的。但是，如果 Microsoft 决定取代/弃用 NTFS（他们确实一度非常接近），那么您将不得不争先恐后地升级您的软件，以便它可以在较新的计算机上运行。
尽管这种可能性现在看起来不太可能，但我认为这比突然发现自己无法连接存储在用户 AppData 中的 SQLCE 数据库或 XML 文件更不可能。
话虽如此，我确信在某些情况下使用 ADS 是合理的。在我看来，这只是其中一种情况，如果您完全确定它是正确的工具，那么它可能就是错误的工具。
一般来说，将元数据附加到文件是一个危险的游戏。只要看看 ID3 所造成的邪恶混乱以及人们将 EXIF 数据留在图像中的令人尴尬的结果即可。
PS 注册表清理程序不再使用了吗？为什么没有人告诉我！？
I can think of one good reason not to use them, and that's this little tidbit from their "how to use" guide:
Now... the way this is worded, I guess, technically you're safe. But if Microsoft ever decides to supersede/deprecate NTFS - and they did come pretty close at one point - then you're going to have to scramble to upgrade your software so it runs on newer machines.
As unlikely as that possibility may seem now, I think it's less unlikely than suddenly finding yourself unable to wire up a SQLCE database or XML file stored in the user's AppData.
Having said that, I'm sure that there are some scenarios that justify the use of ADS. In my opinion it's just one of those cases where, if you aren't absolutely sure that it's the right tool, then it's probably the wrong one.
Attaching metadata to files in general is a dangerous game. Just look at the unholy mess that is ID3 and the embarrassing results of people leaving the EXIF data in images.
P.S. Registry cleaners aren't used anymore? Why didn't anybody tell me!?
备用数据流对于 NTFS 至关重要，并且将始终受到支持。
当它们附加的文件被删除时，它们也会被删除 - 所以不用担心它们“留下来”
正如所有其他人所说，存在备份、复制到其他文件系统以及有关 ADS 的偏执问题。
Alternate data streams are essential to NTFS and will always be supported.
When the file they are attached to gets deleted they get deleted as well - so no worries about them "sticking around"
As all the others have said, there are issues with backup, copy to other filesystem and paranoia regarding ADS.
如果您的应用程序可以在没有这些数据的情况下运行（例如根据需要重新创建它），那么数据流是完全可以接受的。
考虑到它们在 Windows 中的使用方式，我认为它们不会很快消失。
If your app can function without that data, for example recreating it as necessary, the data streams are perfectly acceptable.
Given how they are used in windows, I don't think they are going away anytime soon.
对你来说是个坏主意，对 MS 来说也是个坏主意。我认为它们实际上是与当时 Mac 的数据和资源分支文件架构竞争的尝试。如果 Mac FS 文件可以有 2 个分叉，那么我们将拥有无限的“分叉”，也许我们最终会弄清楚如何使用它们。
Bad idea for you, bad idea for MS. I think they were really an attempt to compete with the Mac's data and resource fork file architecture back in the day. If the Mac FS files can have 2 forks, then our will have unlimited "forks", and maybe we'll eventually figure out how to use them.
将 AltD 添加到文件中作为将特定于应用程序的字符串绑定在文件周围的方式存在您引用的问题：没有清理。如果该文件得到副本，您的东西就会随之而来。对于这种情况，保留一个单独的数据库可能更明智。
另一方面，如果文件完全在您自己的控制之下，那么如果 AltD 是完成这项工作的有效方法，请继续。
Adding an AltDs to a file as a way to tie an application-specific string around it has the problem you cite: no cleanup. And if the file gets copies, your stuff follows it around. For this case, keeping a separate database is probably more virtuous.
If the file, on the other hand, is very much under your own control, then if AltDs is an efficient way to do the job, go ahead.
到目前为止我还没有听到的一件事是在必须隐藏某些类型的信息的应用程序（即医疗应用程序）中使用 AltDS，而希望不隐藏其他类型的信息。
我喜欢 AltDS 的原因正是：我可以设计一个医学成像系统，在其中我可以将医学图像保持在开放状态（例如 BMP），而无需任何患者信息详细信息，因为我可以将这些信息保留在 AltDS 中。宾果游戏。
优点：如果有人将文件复制到拇指驱动器 - 那么，该人获得的只是不包含患者信息的 BMP。
备份/恢复总是令人讨厌 - 我的解决方案是在备份上转移到专有文件格式，其中患者信息在与（原始）BMP 相同的文件中进行编码/加密。
最后，如果您以 XML 格式存储隐藏信息，您的应用程序可能会消失，但信息仍然存在。该信息应链接到文件本身，而不是应用程序。那可能应该存储在其他地方。
总的来说，我喜欢 AltDS。缺乏操作系统支持（看不到 AltDS 数据）、缺乏一般/公共知识（谁？什么？广告？什么样的广告）以及我不必担心需要保留的附加信息与主文件（ahem Stream）同步使我能够设计和实现真正强大的系统。
备份是一个无赖 - 特别是 Joliet 应该被设计来处理那些 AltDS - 但我可以忍受它。
只是我的 2c（好吧，也许是 3c...）。
One thing I did NOT hear so far is using AltDS in applications where certain kind of information MUST be hidden (i.e. Medical applications), while it is desired to NOT hide other kind of information.
The reason I LOVE AltDS is exactly that: I can design a Medical Imaging system, where I keep medical images in the open (as BMP, i.e.) w/o any patient information details, because those I can keep in an AltDS. Bingo.
Advantage: If somebody copies the files to a thumb-drive - well, all that person gets is the BMP w/o the patient info.
Backup/Restore is always nasty - my solution was to move to a proprietary file-format on the backup, where the patient info is encoded/encrypted in the same file as the (raw) BMP.
Lastly, if you store the hidden information in XML format, your application may be gone but the information is still there. The information should be linked to the file itself, not the application. That should probably be stored somewhere else.
Overall I L-O-V-E AltDS. The lack of OS support (can't see the AltDS data), lack of general/public knowledge (who? what? Ads? What kinda advertisements) and the fact that I don't have to worry about that additional information to keep in sync with the main file (ahem Stream) allows me to design and implement really robust systems.
The Backup is a bummer - especially Joliet should have been designed to handle those AltDS - but I can live with it.
Just my 2c (well, maybe 3c...).