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