我使用 OneDrive，其中相关 Windows 文件夹中的每个文件都是一个重新解析点（可通过 dir /al 看到）。当我清除特定文件的 Windows 空间时，它将变成一个占位符，其大小显示在相关 dir 输出中的括号中；同时（显然）仍然是一个重新解析点。当我使用该文件时，它会返回到磁盘，括号会消失，但它仍然是一个重新解析点。这是有道理的。
我还有一个使用 SmartSync 的大型 Dropbox 文件夹。
当 SmartSync 文件处于仅在线状态时，它将被视为重新解析点，文件显示为占位符，大小用括号括起来，空间肯定未被占用。
当它处于本地状态时，它不再是一个重新解析点，并且该文件也不是占位符。
到目前为止，一切都很好。
但是，如果我使用对于仅在线的文件，它似乎最终处于一种中途状态，不再显示为重新解析点；它肯定在磁盘上可用（使用空间）；但它仍然显示为带有括号中大小的占位符。
更糟糕的是，如果我使用 robocopy 复制一个仅在线的文件，它会失去其重新解析点状态（因为它已被使用），保留一个带括号的占位符，并最终到达目标及其所有数据，但也会在那里标记为带括号的占位符（看起来令人担忧，好像目标可能仍然依赖 Dropbox 获取其数据 - 但显然不是，而且目标文件无论如何也不是重新解析点）。
有人能解释一下 Dropbox 占位符的这些奇怪行为吗？我在网上找不到任何关于它的讨论（尽管我可能错过了一些东西）。
答案1
dir当文件具有“脱机”属性时显示括号（文件_属性_离线)。但是，这并不表示该文件实际上是任何类型的“占位符”——它只是意味着 Dropbox 忘记取消设置该属性。
这对我来说是意料之外的，但似乎可以在任何文件上任意设置/取消“离线”设置（即使没有相应的机制来实际制作离线），你甚至可以通过该attrib程序进行操作：
C:\> echo Test! > foo.txt
C:\> attrib +o foo.txt
C:\> dir foo.txt
(7) foo.txt
实际上，这可能是 Dropbox 故意为之——请注意，如果父文件夹通过智能同步将文件夹更改为“本地”，则 Dropbox 也会从所有文件中删除“离线”属性。但是，如果通过智能同步将文件夹设置为“仅在线”，则即使下载的文件也会保留“离线”属性，这或许意味着它们被视为“临时缓存”，而 Dropbox可能当磁盘空间不足时，将它们转换回仅在线状态。
用于fsutil reparsepoint query查看重新解析点的“重新解析标签”内容。
用于fsutil file layout检查 NTFS 文件的结构。如果它确实包含数据，则::$DATA流将显示为具有正确的分配大小。
（忽略“：com.dropbox.attrs：$DATA”的存在；这是一个普通的备用数据流 - xattr - 它是被动的并且不会影响文件系统行为。）