当使用 MS Word 更新文件时,Azure 存储文件共享丢失元数据

Azure Storage File Share looses metadata when files updated with MS Word

我们正在通过 Azure 存储帐户使用文件共享。作为我们应用程序的一部分,我们为每个文件分配 ID 并将此 ID 存储在元数据中:

通过此代码块设置此 ID:

    public static void SetId(this CloudFile cloudFile, Guid id)
    {
        cloudFile.Metadata[DocumentDbId] = id.ToString();
        cloudFile.SetMetadata();
    }

然而,当此文件在 Microsoft Word 2013 中编辑时(所有文件都是 .docx),此元数据被清除干净并且我们丢失了引用。

如果我创建一个文本文件,在元数据中为其分配一个 ID,然后使用记事本对其进行编辑,那么此元数据将保留在应有的位置而不会被擦除。

为什么用 MS Word 编辑会擦除元数据?以及如何防止这种情况发生?是否有其他方法来设置不被编辑擦除的任意 ID?

UPD: 只是为了澄清这是我的情况: 我通过 net use K: \http://myaccount.file.core.windows.net \tests /u:AZURE\myaccount uNrI0yyRxyMx 将文件共享挂载到我的本地驱动器,我在驱动器上放了一个 .docx 文件。在 MS Azure 存储资源管理器中,我右键单击该文件,添加元数据 - 任何元数据,保存它(如上所述使用 C# 进行尝试,但结果是一样的)。再次检查以验证元数据是否已保存。然后在 MS Word 中从安装的驱动器中打开此文件,进行更改并保存。去检查文件上的元数据,那里什么也没有。

但是如果我创建一个 txt 文件,添加元数据,然后用记事本++编辑文件,保存它。元数据不会被清除。所以 MS Word 会擦除元数据

我有一个 confirmation from Microsoft engineer Json Shay MS Word 在写入文件时做一些奇怪的事情:

The reason is that MS Word (and many applications) use the Win32 ReplaceFile() API when saving a file, which is effectively a set of move+move+delete operations. Specifically, MS Word:

Writes the new version of the file into a new temporary file, which contains no properties: ~newfile.docx Rename existingfile.docx --> existingfile_backup.docx Rename ~newfile.docx --> existingfile.docx Delete existingfile_backup.docx The properties were written on the original existingfile.docx, which then gets renamed away, and then deleted.

This is different than notepad, which is modifying the existing file in-place.