使用GetMetadata判断Azure Blob存储文件夹存在性始终返回true问题

这个问题的核心在于Azure Blob存储没有真正的文件夹结构——所谓的“文件夹”只是Blob路径中的前缀部分，Get Metadata活动判断的是这个前缀是否存在（而非该前缀下是否有实际内容）。在你的例子里，test/2018/5/24存在文件，意味着test/2018/5/这个前缀是有效的，当你检查test/2018/5/25时，Get Metadata会认为这个前缀属于已存在的父前缀分支，因此返回exists: true，但实际上这个子路径下没有任何文件。

下面是几个可行的解决思路：

思路1：通过List Blobs活动检查目标路径下的文件 #

这是最可靠的方法，直接验证目标“文件夹”下是否存在实际的Blob文件：

• 在Data Factory管道中添加一个List Blobs活动，配置对应的Azure Blob数据集：
  • 将folderPath设置为目标路径的父级（比如test/2018/5/）
  • 设置prefix为25/（这样会列出所有路径以25/开头的Blob，也就是test/2018/5/25/下的文件）
• 添加一个If Condition活动，判断List Blobs活动的输出（@activity('ListBlobs1').output.value）是否为空：
  • 如果为空，说明test/2018/5/25下没有任何文件，即该“文件夹”不存在
  • 如果不为空，则说明该路径下有文件，“文件夹”存在

思路2：用零字节占位Blob模拟真实文件夹 #

如果你需要明确标记某个“文件夹”存在，可以手动创建一个零字节的Blob作为占位符（比如路径为test/2018/5/25，无后缀），然后用Get Metadata活动直接检查这个占位Blob的存在性：

• 修改数据集配置：

  {
    "name": "metdatatest",
    "properties": {
      "linkedServiceName": {
        "referenceName": "xxx",
        "type": "LinkedServiceReference"
      },
      "type": "AzureBlob",
      "typeProperties": {
        "format": {
          "type": "TextFormat"
        },
        "fileName": "25",
        "folderPath": "test/2018/5/"
      }
    }
  }
  

• 此时Get Metadata活动的exists字段会准确返回这个占位Blob是否存在，从而判断“文件夹”是否被标记为存在

思路3：通过Get Metadata的childItems字段验证 #

如果你坚持使用Get Metadata活动，可以修改配置获取目标父路径的childItems，然后检查是否包含目标子路径：

• 修改Get Metadata活动的fieldList，添加childItems
• 将数据集的folderPath设置为父路径test/2018/5/
• 在后续活动中，遍历childItems集合，检查是否有name等于25的项（这里的name对应子路径/占位Blob的名称）

需要注意的是，childItems只会返回直接子项——如果目标“文件夹”下有文件但没有创建占位Blob，childItems里不会显示25这个项，只有当存在占位Blob或者直接子文件夹（同样是占位Blob）时才会出现。

内容的提问来源于stack exchange，提问作者Anders