我知道这篇文章已经提到了这一点,但我希望对此有更多的澄清。
目前,使用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 方面),它看起来就像是一个严格的删除和一个新文件的进来。
如果您将这些文件中的数据存储在其他地方(如数据库中)并且您需要更新记录而不是创建新记录并删除旧记录,这可能会出现问题。
重命名后是否有一些公认的方法来跟踪文件关联?我似乎找不到使用元数据、增量或修订的方法。