Dropbox API、重命名和唯一 ID

Question

我知道 this post 中已经谈到了这一点，但我希望对此有一些额外的澄清。

目前，与 Dropbox Core API ，似乎没有办法跟踪已重命名的文件。例如，如果您使用 API 将 Dropbox app_folder 与本地应用程序目录同步。您在 Dropbox 端重命名该文件，然后调用 delta要了解如何更新本地应用程序目录，您将返回两个条目...

array(
    0 => '/somefile.txt',
    1 => null
),
array(
    0 => '/somefile-renamed.txt',
    1 => array(
        'revision' => 343
        'rev' => 'd90se4c661'
        'thumb_exists' => false
        'bytes' => 1263
        'modified' => 'Tue, 09 Apr 2013 19:06:39 +0000'
        'client_mtime' => 'Tue, 09 Apr 2013 18:43:06 +0000'
        'path' => string '/somefile-renamed.txt'
        'is_dir' => false
        'icon' => 'page_white_text'
        'root' => 'app_folder'
        'mime_type' => 'application/octet-stream'
        'size' => '1.2 KB'
    )
)

对于返回的每个数组，第一个元素是需要更新的文件，第二个元素是文件元数据信息。如果第二个元素为 null，则应删除该文件的本地版本(以及其下的所有内容，如果它是目录)。

因此，在上面的示例中，它告诉您删除第一个文件并上传这个全新的文件。不幸的是，没有办法跟踪您被告知创建的这个新文件实际上只是您被告知删除的文件的重命名版本。从应用程序的角度(非 Dropbox 端)来看，它看起来就像是一次直接删除和一个新文件进入。

如果您将这些文件中的数据存储在其他位置(例如数据库中)并且您需要更新记录而不是创建新记录并删除旧记录，这可能会出现问题。

是否有一些公认的方法可以在重命名后跟踪文件关联？我似乎找不到使用元数据、增量或修订的方法。

Answer 1

我认为 Dropbox 不知道重命名和删除/添加文件之间的区别。每次我重命名硬盘上本地 Dropbox 文件夹中的文件时，我都会立即看到旧文件重新出现，并覆盖“已删除”图标，而新文件则显示“正在上传”图标。

您也许能够通过比较已删除和创建的文件的内容(也许还比较时间戳)来以合理的精度检测重命名，但即使如此，它也是不确定的。