Unable to retrieve folder revisions through /metadata using rev parameter.

[PIttsburgh Menn]

When I attempt to retrieve a folder's specific revision through /metadata I get back an error indicating that the rev is invalid or outdated.
The documentation is worded such that this seems to be a valid thing to request. And it makes sense since it seems like the rev should change in between deletes and creates. Maybe this isn't the case.

I also checked pretty carefully, and this is definitely the rev being returned by the API when doing a normal /metadata call without the rev parameter.

Sample request:

GET https://api.dropbox.com/1/metadata/auto/Test?list=False&rev=65330698e28 HTTP/1.1
Authorization: Bearer _________
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml
User-Agent: RestSharp/104.4.0.0
Host: api.dropbox.com
Accept-Encoding: gzip, deflate

Response:

HTTP/1.1 400 Bad Request
Server: nginx
Date: Thu, 14 May 2015 17:40:41 GMT
Content-Type: application/json
Connection: keep-alive
Content-Length: 48

{"error": "Invalid or outdated rev 65330698e28"}

Any ideas what could be going wrong? This works just fine for files.
Thanks for the help.

[PIttsburgh Menn]

I just did some testing with the /revisions and /restore calls. I'm getting back a path not found when trying to reference a folder.
Here is the /revisions request and response.

Request:

GET https://api.dropbox.com/1/revisions/auto/Test?rev_limit=1000 HTTP/1.1
Authorization: Bearer ___________________________
Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml
User-Agent: RestSharp/104.4.0.0
Host: api.dropbox.com
Accept-Encoding: gzip, deflate

Response:

HTTP/1.1 404 Not Found
Server: nginx
Date: Thu, 14 May 2015 18:13:02 GMT
Content-Type: application/json
Connection: keep-alive
Content-Length: 35

{"error": "Path '/Test' not found"}

The API is a little clearer on this one. Though it doesn't explicitly say /revisions and /restore only work with files, it does use the word file any time it references the items being retrieved rather than the usual "file or folder". From this, it appears that the Dropbox API only supports using revs with files. If this is indeed the case though, why do folders have revs that get returned? And how would you go about restoring a deleted folder?

[Greg-DB]

Thanks for the detailed post, and sorry the documentation isn't clearer on this. Folders do technically have rev values (due to the specifics of how this works on the backend) but /revisions and /restore only work with files, not folders.

Likewise, /metadata with a rev parameter isn't meant to be used for folders, and usually trying to do so gives the more helpful error:

Directories can not be used with the rev parameter

Unfortunately though, in certain cases, you'll get the "Invalid or outdated rev" error message instead.

[PIttsburgh Menn]

Alright great thanks for the response, that was exactly what I needed to know.

[Daniel E.2]

Quick question related to this: how does this work when a folder is deleted and then a file is created with the same name?

Suppose I delete a folder, then decide I want to list the files it used to contain. Retrieving its metadata with list=true and include_deleted=true will give me the list of all files and folders that were formerly under that path. But, if I then create a file with the same name as the deleted folder, retrieving its metadata will only give me the metadata of that new file. I can't call /metadata with the former folder's rev, because revs aren't allowed.

My guess is that I'd have to delete the file, manually create a new folder at its path, and then call /metadata with list and include_deleted, do whatever I wanted to do with the result, then delete the folder again and restore the file I deleted with a /restore call. Is that right?

[Greg-DB]

Yes, unfortunately things can get complicated like that when a particular path has been both a file and a folder, but I believe your described workaround is right.

[Samson B.]

Thanks for your answers Gregory. I was doing something similar and could see from the 400 code that was returned to me that I can't get the "revisions" for a folder. However, what can be done instead? I have a list of 730 folders. Anytime the name changes on one of them, I need to change the name of an item in a separate database. The problem is, without the revisions, I'm not sure how to get the OLD name in order to find the item to change in my connected database. I set up a poll for new directories under a given path, which will catch when folders are renamed, but it will only give me the NEW name, which isn't helping for finding the old value in my database to change it. (on top of this issue, the "new directory" poll will also catch brand new folders, instead of just those that are renamed, which causes other issues as well.) Could I get some help? Maybe "/delta" is the key, but not sure how to structure the solution in my case. 

[Leah C.1]

Hi Samson,

There's no way to get the previous name of a folder by the current folder name. However, in the new API v2, you can use the "id" parameter returned by the API to identify the folder.

So perhaps you could store the "id" along with the folder name/path. Then when you see a new folder, check if the id of the folder already exists in your database and update its name/path.

Hope that helps!
Leah

[Samson B.]

Leah, that is exactly the kind of thing that I am looking for, but when a new folder is created, and my hook is triggered, I'm not being returned an "ID" for the folder. The info that is returned to me in a JSON is the following:

read_only: False
icon: folder
bytes: 0
thumb_exists: False
rev: 735536ee77aa
modified: Tue, 31 May 2016 19:21:06 +0000
folder_name: Framework LTD DBA
path: /Tester/Valuation/Framework LTD DBA
is_dir: True
size: 0 bytes
root: dropbox
share_link: (hidden)
revision: 29525
modifier: (blank)

[Leah C.1]

It looks like you're using Dropbox API v1 which doesn't have the IDs. Only API v2 has IDs for files (it's a new feature): https://www.dropbox.com/developers/documentation/http/documentation#files-get_metadata

My suggestion would be to switch to the new API v2 if possible. If not, there may be other ways to make a best guess as to if a folder has been renamed, such as a new folder having the same contents as a previous folder. However this would only be a guess.