I know this has been touched upon in this post, but I was hoping for some additional clarification about this.
Currently, with the Dropbox Core API, there doesn't seem to be a way to track files that have been renamed. For example, if you're using the API to sync a Dropbox app_folder with a local application directory. You rename the file on the Dropbox side and then call delta
to see how you should update your local application directory, you're returned two entries...
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'
)
)
For each array returned, the first element is the file that requires an update and the second element is the file metadata info. If the second element is null
, you should delete your local version (and anything under it, if it's a directory) of that file.
So, in the above example, it's telling you to delete the first file and upload this completely new file. Unfortunately, there's no way to track that this new file that you have been told to create was actually just the renamed version of the file you're being told to delete. From your application's perspective (the non-Dropbox side), it just looks like a strait delete and a new file coming in.
This can be problematic if you're storing the data in these files elsewhere (like in a database) and you need to update the record instead of creating a new record and deleting the old one.
Is there some accepted way to track file association after a rename? I can't seem to find a way to do it using metadata, delta or revisions.