logo标签列表

NTFS备用数据流-好主意还是坏主意？

architecturentfsalternate-data-stream
7
我希望为文件存储一些与应用程序有关的元数据，而NTFS备用数据流（AltDS）可以让我将这些元数据直接存储在文件上，而不是在单独的数据库中。但我认为这并不是一个好主意。我知道这只适用于NTFS文件系统，但至少如果用户将文件复制/移动到非NTFS驱动器中，他们会收到来自Windows的警告。而且，在文件上存储额外的数据可能会变得非常浪费，因为即使我的应用程序被卸载，AltDS仍然存在。这就像十年前人们使用“注册表清理程序”从注册表中删除无用条目以加快系统运行速度（当清理程序清理太多时，系统变得不稳定…）。我想知道它们可以合理地用于什么？它们应该完全留给微软应用程序使用吗？还是有一些通用政策可以规定哪些类型的应用程序可以使用它们（除恶意软件之外）？编辑：只是为了澄清我的想法。我正在为自己撰写一个小型文档管理系统。因为我想要自由地移动文件，所以我想将元数据存储在文件上，以便如果我移动/重命名/修改它们，我的应用程序仍然能够识别它们。它可以是整个元数据，也可以是与单独数据库配合使用的GUID。总之，这样做的优点是元数据随着文件移动，因此无需通过哈希或文件名识别它，而且适用于所有文件类型，即使是.txt文件，在其中无法存储任何数据。缺点有：只适用于NTFS，这可能不是未来Windows版本的默认文件系统；AltDS即使我的应用程序被卸载仍然存在；隐私问题；易碎：大多数USB闪存驱动器都是FAT32格式。许多私人文件服务器都是Linux。从Internet下载文件时应仅传输文件而不是流。简而言之，很容易失去它们。
8个回答
6

另一个难点：备份软件。有些忽略它，有些不恢复它，有些支持它但没有你告诉它就不会执行任何操作。

4

没有更多关于您存储的数据类型的信息很难说。 您似乎已经意识到了其中一些使用方面的问题，所以我不确定我能提供多少帮助。 不过，这是我对备用数据流的一般想法：

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

除此之外，我想不到任何技术原因来避免使用AD流，但我仍然会谨慎使用它们。人们往往对“隐藏”数据的应用程序感到紧张，无论意图如何。考虑索尼根套件事件等。我并不是说你的应用程序和那个一样糟糕，但人们（尤其是不太懂技术的人）可能不会区分。不过，我承认他们可能有一个有效使用你的应用程序的理由。当然，在卸载后留下AD流的问题仍然非常真实。您可能需要考虑为运行卸载程序的人提供运行程序以搜索他们的驱动器并清理任何剩余流的选项。
此外，请记住KISS principle。使用AD流是否真的是解决应用程序元数据存储问题的最简单方法？如果是，也许AD流是一个好主意，但如果不是，我会认真考虑采取另一种方法。
谢谢。这些数据是文档管理系统的元数据。这主要是为了自己而进行早期规划，但我遇到了AltDS并想收集一些意见。"隐藏数据"部分实际上是一个很好的观点。只有极少数用户真正试图保护自己免受恶意软件的侵害（几乎每个人都愿意安装带有可爱吉祥物的垃圾应用程序），但大多数人在有人指责某个应用程序是恶意软件时很快就会加入讨论，即使这是毫无根据的。 - Michael Stum
3
我能想到一个不使用它们的好理由，就是在他们的"如何使用"指南中有这样一条小贴士：
交替数据流严格是NTFS文件系统的特性，可能在未来的文件系统中不被支持。然而，NTFS将在Windows NT的未来版本中得到支持。
现在...从措辞上看，我猜你可以说是安全的。但如果微软决定超越/弃用NTFS - 他们曾经在某个时候非常接近 - 那么你将不得不赶紧升级你的软件，以便在新的机器上运行。
尽管这种可能性现在似乎不太可能发生，但我认为这比突然发现无法连接存储在用户AppData中的SQLCE数据库或XML文件的可能性要小。

话虽如此，我相信有些情况下使用ADS是有正当理由的。在我看来，这只是其中一种情况，如果你不绝对确定它是正确的工具，那么它很可能是错误的。

通常给文件添加元数据都是危险的游戏。只需看看ID3的混乱和人们遗留图像中EXIF数据的尴尬结果就知道了。

P.S. 注册表清理程序已经不再使用？为什么没有人告诉我！？

1
好的观点。是的，WinFS本来应该取代NTFS，但据我所知，WinFS仍支持元数据（因为它本质上是一个嵌入式SQL Server操作系统）。至于ID3和EXIF：它们存储在文件本身中，但这是一个很好的观点。我还没有检查过如果我从NTFS服务器通过IIS下载文件到NTFS文件系统会发生什么 - 我希望它会杀死AltDS，但还没有检查。我的用法类似于EXIF，它是用于文档管理系统，我希望在移动文件时数据（实际上只是GUID）也能随之移动。 - Michael Stum
2

备用数据流对NTFS非常重要，并且始终会得到支持。当它们所附加的文件被删除时，它们也会被删除 - 因此不必担心它们“留存”。

正如其他人所说，备份、复制到其他文件系统以及对备用数据流的偏执症问题存在一些问题。

1
如果您的应用程序可以在没有这些数据的情况下正常运行，例如必要时重新创建它们，则数据流是完全可接受的。
考虑到它们在Windows中的使用方式，我认为它们不会很快消失。
1

这对你来说是个坏主意，对微软也是个坏主意。我认为当时它们真的是试图与 Mac 的数据和资源 fork 文件架构竞争。如果 Mac 文件系统文件可以有 2 个 fork，那么我们的将拥有无限的“forks”，也许最终我们会想办法如何使用它们。

我在思考这些问题。据我所知，Mac OS使用第二个fork来存储文件的元数据，例如应用程序和类型描述符（因为它不依赖于文件扩展名），这使我们能够说“我想用那个编辑器打开这个.txt文件，但是用另一个编辑器打开另一个.txt文件”。这样做是因为它与Finder紧密集成，而Windows资源管理器似乎只使用AltDS来显示烦人的“无法执行此文件，因为它来自互联网”的消息。 - Michael Stum
@MichaelStum：在“旧的Mac OS”文件中，第二个叉子保存了一个非分层的资源集合，每个资源都有一个32位类型（通常由四个可打印ASCII字符表示），一个16位ID，一个可选名称和任意数量的数据（我认为最多可以达到两个G）。 应用程序文件通常在资源叉中拥有所有内容而在数据叉中没有任何内容，但也有例外。 一些文本编辑器将原始文本存储在数据叉中，将制表符等内容存储在资源叉中。 一些应用程序将所有内容存储在其文档的资源叉中。 - supercat
1
实际上，ADS 是专门为了与 MacOS forks 兼容而添加到 NTFS 中的，而不是为了“竞争”它们。有一些工具可以将资源 fork 转换为一致命名的 ADS，反之亦然，以避免在跨操作系统移动文件时出现数据丢失。 - Ti Strga
1

将AltDs添加到文件中作为将应用程序特定字符串绑定在其周围的一种方式存在您所引用的问题：没有清理。如果文件被复制，您的东西也会跟随它。对于这种情况，保持单独的数据库可能更加正义。

另一方面，如果文件非常在您自己的控制下，则如果AltDs是执行任务的有效方法，请继续。

0

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

我之所以喜欢AltDS，正是因为这个原因：我可以设计一个医学成像系统，在其中保持医学图像的开放性（例如BMP），而不包含任何患者信息细节，因为那些我可以保存在AltDS中。优点：如果有人将文件复制到大拇指驱动器中，那么该人只能得到没有患者信息的BMP文件。

备份/还原始终很麻烦-我的解决方案是转移到专有文件格式上进行备份，其中患者信息编码/加密在与（原始）BMP相同的文件中。

最后，如果您将隐藏信息存储为XML格式，则您的应用程序可能已经不存在，但信息仍然存在。 信息应该链接到文件本身，而不是应用程序。 这可能应该存储在其他地方。

总的来说，我非常喜欢AltDS。虽然它缺乏操作系统支持（无法查看AltDS数据），一般公共知识也匮乏（谁？什么？广告？是什么样的广告），但我无需担心与主文件（咳咳流）同步的其他信息，这使我能够设计和实现非常稳健的系统。

备份有点烦人——特别是Joliet应该被设计为处理那些AltDS——但我可以忍受它。

这只是我的2分钱意见（好吧，也许是3分钱……）。

2
如果Thumb驱动器以NTFS格式格式化，则AltDS也随之而来，但其中的所有信息都必须加密。但是你的情况正是我考虑的情况：在保持文件本身不变的情况下附加元数据。 - Michael Stum
7
作为一名安全工程师，我对这篇文章的写作方式感到非常担忧。备用数据流并不是一种安全功能，仅仅因为在Windows资源管理器中看不见它们，并不意味着它们可以作为安全屏障或者不能被查看。如果你对元数据进行加密那倒是可以，但是依赖于它们在资源管理器中不可见或者有时不会跟随文件被复制这一点作为安全措施是非常危险的。 - Peter Oehlert
1
“安全通过模糊性”是一种不可取的做法。一想到医疗隐私法数据可以被任何会在我的X射线位图末尾键入“：space_dude_alien's_secret_stuff”的人轻松获取，我就感到不寒而栗。 - Ti Strga
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接