7

我想为文件存储一些与应用程序相关的元数据，而 NTFS 备用数据流 (AltDS) 将允许我将此元数据直接存储在文件中，而不是存储在单独的数据库中。

我只是觉得这不是一个好主意。我知道这仅适用于 NTFS，但至少如果用户将文件复制/移动到非 NTFS 驱动器，他们会收到来自 Windows 的警告（是的，是的，我知道没有人阅读警告）-

而且，在文件上存储额外的数据可能会变得非常浪费，因为即使我的应用程序被卸载，AltDS 也会保留。就像十年前，人们在卸载程序后使用“注册表清理器”从注册表中删除无用的条目以使他们的系统运行得更快（并且当清理器清理太多时稳定性会降低......）。

我只是想知道它们可以合理地用于什么？它们是否应该完全留给 Microsoft Apps 使用？或者是否有某种共同的政策，哪些类型的应用程序可以使用它们（恶意软件除外）？

编辑：只是为了澄清我的想法。我正处于为自己编写一个小型文档管理系统的早期阶段。因为我想自由移动文件，所以我想在文件上存储元数据，这样如果我移动/重命名/修改它们，我的应用程序仍然可以识别它们。它可以是整个元数据，也可以只是与单独数据库一起使用的 GUID。

总结给出的要点：

优点：

  • 元数据随文件移动，因此无需通过散列或文件名识别它
  • 适用于所有文件类型，甚至是无法在文件本身中存储任何数据的 .txt 文件

缺点：

  • 仅适用于 NTFS，在未来的 Windows 版本中可能不是默认文件系统
    • 尽管如果 MS 在将 WinFS 放在一起时不会自动转换它们，我会感到惊讶
  • 即使我的应用程序被卸载，AltDS 仍然存在
  • 隐私问题
  • 脆弱的
    • 大多数 USB 记忆棒都是 FAT32。许多私有文件服务器都是 Linux。从 Internet 下载文件应该只传输文件而不是流。简而言之：失去它们相当容易。
4

8 回答 8

6

另一个症结所在：备份软件。有些人忽略它，有些人不恢复它，有些人支持它，但在没有你告诉它的情况下不做任何事情。

于 2009-12-30T04:33:34.893 回答
4

如果没有有关您存储的数据类型的更多信息，很难说。您似乎知道一些涉及使用它们的问题，所以我不确定我能提供多少帮助。不过，这是我对备用数据流的一般看法：

首先，正如您所指出的，AD 流仅适用于 NTFS。如果有任何机会需要将此元数据存储在 FAT 文件系统上，则需要某种回退机制。现代 PC 可能具有 NTFS 格式的内部硬盘驱动器，但您遇到的大多数 USB 闪存驱动器仍然是 FAT 格式的。如果您的用户将数据文件存储在闪存驱动器上，请记住这一点。

除此之外，我想不出任何技术上的理由来避免广告流，但我仍然对使用它们持谨慎态度。人们往往对“隐藏”数据的应用程序感到紧张，无论其意图如何。考虑一下 Sony rootkit 的惨败，等等。我并不是说你的应用程序有那么糟糕，但人们（尤其是技术不太熟练的人）可能无法区分。不过，我会允许它们可能对您的应用程序有有效的用途。当然，卸载后留下广告流的问题仍然非常现实。您可能需要考虑让运行卸载程序的人选择运行程序来搜索他们的驱动器并清理任何剩余的流。

另外，请记住KISS 原则。使用 AD 流真的是有效解决应用程序元数据存储问题的最简单方法吗？如果是这样，也许 AD 流是一个好主意，但如果不是，我会认真考虑采用另一种方法。

于 2009-12-30T03:57:44.107 回答
3

我可以想到一个不使用它们的好理由，这就是他们的“如何使用”指南中的这个小花絮：

备用数据流严格来说是 NTFS 文件系统的一项功能，未来的文件系统可能不再支持。但是，Windows NT 的未来版本将支持 NTFS。

现在……我猜，按照这种措辞，从技术上讲，你是安全的。但是，如果微软决定取代/弃用 NTFS——而且它们确实在某一时刻非常接近——那么你将不得不争先恐后地升级你的软件，以便它在更新的机器上运行。

尽管这种可能性现在看起来不太可能，但我认为这比突然发现自己无法连接存储在用户 AppData 中的 SQLCE 数据库或 XML 文件的可能性要小。

话虽如此，我确信在某些情况下可以证明使用 ADS 是合理的。在我看来，这只是其中一种情况，如果您不确定它是否是正确的工具，那么它可能是错误的。

将元数据附加到文件通常是一种危险的游戏。看看 ID3 的烂摊子，以及人们将 EXIF 数据留在图像中的尴尬结果。

PS 注册表清洁器不再使用？为什么没有人告诉我！？

于 2009-12-30T03:58:02.483 回答
2

备用数据流对 NTFS 至关重要，并且将始终受到支持。当他们附加到的文件被删除时，他们也会被删除 - 所以不用担心他们“坚持”

正如所有其他人所说，备份、复制到其他文件系统以及关于 ADS 的偏执都存在问题。

于 2010-08-24T14:17:21.067 回答
1

如果您的应用可以在没有这些数据的情况下运行，例如根据需要重新创建它，那么数据流是完全可以接受的。

鉴于它们在 Windows 中的使用方式，我认为它们不会很快消失。

于 2009-12-30T03:55:58.820 回答
1

对你来说是个坏主意，对 MS 来说是个坏主意。我认为它们确实是当时与 Mac 的数据和资源分叉文件架构竞争的一种尝试。如果 Mac FS 文件可以有 2 个分叉，那么我们将拥有无限的“分叉”，也许我们最终会弄清楚如何使用它们。

于 2009-12-30T03:56:34.310 回答
1

将 AltD 添加到文件中作为将特定于应用程序的字符串绑定在其周围的方法存在您引用的问题：没有清理。如果文件得到副本，你的东西就会跟着它走。在这种情况下，保留一个单独的数据库可能更有益。

另一方面，如果文件在很大程度上由您自己控制，那么如果 AltDs 是完成这项工作的有效方法，那就继续吧。

于 2009-12-30T03:58:15.510 回答
0

到目前为止我没有听到的一件事是在必须隐藏某种信息的应用程序（即医疗应用程序）中使用 AltDS，同时不希望隐藏其他类型的信息。

我喜欢 AltDS 的原因正是：我可以设计一个医学成像系统，在其中我将医学图像保持在开放状态（如 BMP，即），不包含任何患者信息细节，因为我可以将这些图像保存在 AltDS 中。答对了。优势：如果有人将文件复制到拇指驱动器 - 好吧，那个人得到的只是没有患者信息的 BMP。

备份/恢复总是令人讨厌 - 我的解决方案是在备份上转移到专有文件格式，其中患者信息在与（原始）BMP 相同的文件中编码/加密。

最后，如果您以 XML 格式存储隐藏信息，您的应用程序可能会消失，但信息仍然存在。信息应该链接到文件本身，而不是应用程序。那可能应该存储在其他地方。

总的来说，我喜欢 AltDS。缺乏操作系统支持（看不到 AltDS 数据），缺乏一般/公共知识（谁？什么？广告？什么样的广告）以及我不必担心要保留的额外信息这一事实与主文件（ahem Stream）同步使我能够设计和实现真正强大的系统。备份是一个无赖 - 尤其是 Joliet 应该被设计来处理那些 AltDS - 但我可以忍受它。

只是我的2c（好吧，也许是3c ...）。

于 2010-12-20T21:16:43.877 回答