Dropbox v2 Support?



Hi @Tony,

So it is August 23, 2017- about 5 months after I initially asked you about odrive’s support for the Dropbox v2 API which was released to the public on November 4, 2015 which provides full metadata support for files so that things like “Date Created”, “File Ownership”, “File Permission Mode”, and so forth were preserved.

To refresh you memory, this is because the lack of full metadata support causes all sorts of problems for people who were previously relying on Dropbox to sync files while preserving this important information so that things like development environments, scripts, and so forth not only were identical across all of my workstations, they would still function as expected. Because odrive only supported v1, things like file ownership, permissions, creation dates, etc… this caused all sorts of breakage at the time for those of use who thought there was equivalent feature support between Dropbox and odrive.

This is an aside of course of the other problem of having files be uploaded and downloaded for no reason even though the files were otherwise identical because of the files having their creation dates changed. Normally it would seem the file cheksums are designed to prevent this, but this method was not fool-proof, so complete repository refreshes occurred inexplicably, which in my case caused the resync of hundreds of thousands of files.

So again, now that we are approaching two years since Dropbox publically announced the vs API - a feature set making it a cloud tool of choice for “power users” who require perfect copies of synced files and metadata - I am left to wonder if this is something that the odrive developers ever plan on implementing or if it is just going to be talked about for eternity. Full file metadata support in Dropbox seems like a high priority item since file sync accuracy is the cornerstone of any cloud sync utility. If you can’t trust the sync, you can’t use the utility. It’s as simple as that.

I have been running with odrive using Google Drive for the bulk of my files which has been fine for most stuff where file metadata is not critical, but for anything that relies on accurate file scripts, sensitive files, etc… I am forced to keep the Dropbox agent running to handle those files which is obviously suboptimal.

Fortunately for odrive, the Mac clients for the other big cloud players like Google Drive (which now uses the already-panned “Backup and Sync” app) and Amazon Cloud (whose cloud sync app for MacOS and iOS iare unquestionably the worst cloud sync agents available, not to mention the very unwelcome change in their pricing structure) are absolutely terrible, so the bar is already pretty low. But at this point, as much as I wish odrive word work properly, wishes don’t keep the lights on, and I am already looking build my own private cloud on my home network using a QNAP device. My patience is just about expired.

If you could find out if there is an updated official target date for the Dropbox v2 API, I would really appreciate it. Quite simply, if there is no support for this 1 year and 10 month old API, I am just going to have to abandon odrive, which I really would like to avoid because it offers so many other user-friendly features. But again, if you can’t rely on file integrity, you can’t use it in good conscience.



Hi @DarfNader,
The current odrive client actually uses the v2 API, but it was a drop-in replacement for V1, so it doesn’t implement anything additional and maintains parity with V1 attributes. This was done to ensure compatibility with the tens of thousands of current odrive Dropbox users.

The next major version uses v2 and makes use of the v2-exposed “client_modified” attribute to try to preserve the original modtime, as it existed on the filesystem when the file was originally uploaded.

The Dropbox V2 API still only natively exposes the basic metadata (name, size, client modtime, server modtime, and some simple media metadata). They have the ability to create custom property templates, where you can define your own metadata, but this is still in a “preview” stage.


Wow, so the basic metadata support that you find on the most primitive OS’s filesystem like preservation of the creation data is something that the odrive engineers have not changed for fear that they have gown accustomed to it working incorrectly and the fear is that fixing that will make some people unhappy because they rely on it being broken? If that is the case, at what point does the dev team decide to implement major bugfixes like? This seems like a way of reporting a bug so that it never gets fixed because some period.

I know it sounds like I a being deliberately snarky and possibly behaving like jerk, but it just sounds like a very strange situation

Imagine this is a fast food restaurant. They make really good french frieds called Lucky Ducky Fries as they are made with duck fat. So incredubl

It’s like a fast food restaurant that discovers that used gym socks were getting in the french-fries’ oil give the fires a funky taste that many many customers prefer, so the company that makes the food has to let this new craze od french fries that have hint of gym-sock flavoring. Instinctively, the process wants to get those stinky socks out the the fryer oil, but then the marketing director blocks her from doing that because it brought in a bunch of new customers who love the taste but have no idea where it comes from. So what do they do? The build a new kit for making fries, one with and one without gym socks. The gymsock free variety is just called Lucky Ducky Classic, which the ones with the new additive are called Lucky Ducky Funky.

Maybe you need to make version emulation just be a switch. This would also be a perfect opportunity actually give your app some settings! Anyway, make such place in your settings for all the cloud providers. I say this is because the feature list for a product shouldn’t be decided on which tool gets to market first, the fact that people are “used” to broken behavior should mean the want it that way. Besides even if they did, it’s an easy command to provide some check boxed to define default behavior. You could also slip the fix in and just have it no be default behavior and then have a notice well in advance and then at some point announce that the “correct” behavior will be the new default. Strange but true.


Hi @DarfNader,
I understand your frustration. Changing this in the current app would’ve caused all odrive Dropbox users local data to be re-downloaded (since the tracked modtimes would change), which would have a huge impact. It would take much more development effort in the current software to try to make the change safe and construct a migration flow to convert all existing sync data to the new dates without side-effects.

We also debated creating a completely separate v2 Dropbox integration for users to create new links to, but there are additional complications with that, in addition to the confusion it would create.

The new functionality (along with new app settings and a ton of other stuff) will be in the major release we are working on.


Hi @Tony,

Thanks for the reply. This is an interesting problem and a bit revealing of odrive. If I am understanding this correctly, the apparent change of the “creation date” is only visible within odrive, meaning in Dropbox the creation times are not affected by the “missing” functionality? I am asking just so I understand the situation as it might help be come up with a good work-around in the meantime. If that is the case, I do see the dilemma as the odrive app would need to be able to somehow flag any existing files before the update and allow them to inherit the correct/original creation dates from Dropbox without the need for a resync. This is indeed a non-trivial bit of functionality.

Anyway, thanks for the explanation for the delay. That does explain a few things and allows for a little empathy for the developers. If you could confirm if my understanding is correct, that would be helpful as I think I could come up with a way to script a means to deal with the API shortfall without having to keep the Dropbox agent running on all of my computers.



Hi @DarfNader,
The crux of the situation is that Dropbox caries two timestamps for their files. In the V1 API they had “modified”, which was the recommended value to use, and then “client_mtime”, which was a timestamp that was only created by the Dropbox native client and not recommended for tracking. Both “modified” and “client-mtime” were not allowed to be modified via the API, so the odrive client wasn’t able to set or change either of them when uploading files.

In our initial development, we found that the “client_mtime” was not a reliable value to use, so it made sense why its use was discouraged. Unfortunately, the “modified” timestamp, although reliable, was a server-side timestamp so it reflected the server’s frame of reference for modified timestamp.

In Dropbox’s V2 API, they have a “server-modified” and a “client-modified” timestamp. “Server-modified” equates to V1’s “modified”. “Client-modified” equates to V1’s “client-mtime”, although its behavior in V2 is more reliable. The V2 API allows the “client-modified” timestamp to be changed, so we can send that with our uploads to retain the original modified timestamp of the file, as it exists on the source machine. We have also seen that this timestamp seems to default to the server-modified time, if the client-modified is unset, which means we can use it as the definitive timestamp from Dropbox in our new implementation.


Hi @Tony,

Thanks for the breakdown. I can understand now what this is a non-trivial transition. I have written some scripts to interact with the Dropbox v2 API and I understand how it is not as straightforward as I might like it to be, especially with how their access token model works.

One last question on this topic and I will leave you alone: is the v1 “server-mtime” value what odrive uses to determine whether a file needs to be synced by keeping that value in its database so that it can determine which file is the newer version and whether or not a change has taken place in two locations in order to detect that a conflict has occurred? If so, I am thinking of ways to script a means to sync the “server-mtime” fields with a script to suppress an odrive sync if something touches the files causing the server-mtime field to get updated, thereby forcing a sync when the files are otherwise identical. This seems to be the behavior, but I wanted to confirm.

As a side note, one thing that would really save on bandwidth for all cloud providers would be the ability to checksum the files before sending them over the wire to spare the internet link from getting swamped. Granted, this would be CPU-heavy and add time to the sync process, so maybe some users would just prefer a time based sync only, so perhaps this could be an option. (Then of course you’d have to have an actual preferences panel in your app, and I know you don’t want that! :wink:)

Thanks again,


Hi @DarfNader,
odrive currently uses “server_modified” (previously “modified”, in V1) for the authoritative modtime in the V2 API. A combination of “server_modified”, “size”, and “rev” is used to try to determine file changes.

The V2 API has a nice addition in that it exposes the content_hash, which is something that can finally be used as an authoritative marker for detecting actual file content changes. This was not available in V1 (really wish it had been). We initially hoped that “rev” and previously “revision” would fit that bill, but the values of those attributes change on renames, moves, content updates, and metadata updates. :unamused:


Hi @Tony, I was just check in to see if there has been any solution to with odrive and Dropbox playing nicely? It was not clear from your last message whether or not content hash is something that odrive now is using for determining whether or not a file needs to be updated or not. It’s been awhile since I tried to see how odrive handles odrive syncing of dropbox files but I have to rebuild my MacBook with HighSierra from scratch and I wanted to see if I can go with odrive for all my file syncing or if I still need to use the Dropbox client separately. It sounds like it’s been handled, but I want to make sure before I do anything that might permanently change my dropbox repository, and since it is made up of a code library that is like 250K files of about 1K each, it takes a very long time to restore. Thanks.


Hi @DarfNader,
We are making use of the content_hash in the next generation odrive product, which is still under development, as you know. The current release of odrive is not able to make use of the content_hash attribute.


Hi @Tony, is there an ETA yet on the next generation of oDrive yet? I don’t want to sound testy, but tomorrow will mark the 2 year anniversary of when Dropbox released v2 of its API, and It has been nearly 8 months since you and I first made each others’ acquaintance here in the oDrive forum which also was the first time which you informed me about oDrive’s forthcoming support of Dropbox v2 API. (This forthcoming support apparently is what incorporates content_hash tag support like you said - the feature necessary to resolving the never-ending upload/download thrash that results if you try keep a file stored on Dropbox synced between two computers using oDrive. Also, I presume that the matter of preserving the file creation date will also be resolved with this release, right?) Anyway, suffice it to say the status of the release of the next generation of oDrive has stayed unchanged for over 8 months, so I was hoping that perhaps there was an update on when we, the paying user base, might get a chance to use it. While I don’t expect that being a paying subscriber means I can demand that the engineers “work faster”, I was hoping that maybe this status would afford me a better estimate as to when I might expect to DropBox functionally supported, as it currently isn’t, not effectively anyway. (Hopefully it will be released before Dropbox releases API v3! :wink:) All kidding aside, if I could get a rough idea when I should expect its release it will help me plan how I do file sync.

Meanwhile, it’s honestly been so long since I have revisited this issue (I have been continuing to begrudgingly use the Dropbox sync agent alongside the oDrive agent for cloud file sync) that I forget all of the pertinent details about this problem. I just remember that it started with my finding the horrible copy thrash issue that I mentioned as it was pegging my CPU and flooding my uplink. The additional issue where the file original file creation date was getting replaced with last transferred date which was also explained to me as the result of the lack of DropBox API v2 support, but I forget the details. In any case, it sounds like I still should continue using the Dropbox agent for a while.

One final question… is there any way to make use of the python CLI script to get around this problem so that I don’t have the thrash issue that I am referring too? Does the behavior of the sync agent differ from the desktop client at all with regards to handling the Dropbox API?

Thanks again,


Hi @DarfNader,
I don’t have a date to give, unfortunately. I can only say that we have a team of engineers (including myself) working on it around the clock and we are trying to finish things up as fast as we can.

For your use case, and based on previous discussions, I think it may be best to stick with the Dropbox-supplied client for the time being.

The CLI can’t be used to get around this behavior, as it has to do with the lower-level tracking that is done by the sync engine.