dsofile c# API / NTFS自定义文件属性

Question

我正在寻找一种将元数据添加到文件的好方法。dsofile.dll在NTFS上工作得很好。当用户在FAT32共享上放置一个副本时，元数据就会丢失(我猜它使用的是NTFS隐藏流)。Microsoft Word文档包含未丢失的元数据，它们如何做到这一点？与FAT类似，通过电子邮件发送文件，其中包含使用dsofile创建的所有元数据(以及使用Windows资源管理器手动创建的元数据)。单独的元数据文件不是一个选项。它必须与标准的Windows技术兼容。如果我向某人发送带有Outlook的文件，而他又将其发回，元数据应该不会丢失。

(需要的元数据实际上只是一个ID)

Answer 1

任何解决方案都依赖于格式。MS OFfice文件是(所有)复合文件，在那里有一个属性的位置。在某些格式(例如PE文件)中，如果您知道如何在以后读取数据，则只将数据附加到文件的末尾是安全的。在ZIP文件中，您可能会在目录中找到一个位置，或者只是将包含您的数据的帮助文件添加到归档中。其他格式无法忍受这一点，您需要找到自己的方法来解决这个问题。

实际上，文件名也可以作为ID的一个很好的占位符。

如果您需要将文件存储在某个位置，但又不需要外部应用程序保持文件的可读性，您可以将它们打包到ZIP存档中，或者使用类似我们的SolFS库的东西。

Answer 2

问题在于，所有文件系统都将文件的单流视图作为最大公分母来提供。通过这个公开文件“content”的接口，您可以读取或存储属性，并通过naive system (或user-)实用程序将它们与“content”一起传输。例如，Windows中的CopyFile会小心地丢失备用数据流，并且没有“影子文件”的概念。

问题是“内容”的格式是否允许任意添加属性。

一些格式允许任意内容(例如，MSFT的文档文件也称为.doc/.xls/等)。有些允许有限的内容(.mp3、.jpg、.exe)。

有些完全是SOL (.txt，.bmp)。

Answer 3

标准属性而不是自定义DSOFile属性又如何呢？Ie评论，作者等？它们会被擦掉吗？

不确定这是否是理想的，但我们已经解决的方法是，我们有一个工具，它将获取DSOfile属性并保存一个文本文件，然后将该文件与文件一起通过电子邮件发送，而在另一端，用户运行一个工具来从文本中重新导入dsofile属性。