nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

API v2 - set metadata/mtime

hemancuso

With the API v2 preview underway, I'd really really love a way to set the mtime and other associated metadata for a particular file. Having it always stamped to whatever the server has makes developing an application to mirror data [or in our case, a filesystem] very challenging. Clearly the desktop client has this ability, so adding some subset of that functionality into the API would be very helpful.

Find more posts tagged with

API

Abuse

Comments

Steve M.

We'll certainly consider this, but I'm curious if you've considered keeping track of revs for syncing. This has a few advantages over using timestamps:

It allows you to sync correctly with more than one computer (without having to have strict clock synchronization requirements).
It allows you to sync correctly even if the time on the local computer changes (e.g. due to correcting clock drift or even things like leap seconds).
It allows you to know when you can safely overwrite a file in Dropbox. (With just a timestamp, you can't tell whether or not a file was modified in the cloud since the last time you uploaded, so you don't know if an overwrite might destroy work from another computer. A conditional upload with a parent rev also avoids clobbering a file in a race condition where the file is modified remotely during an upload.)

FYI, I'm pretty sure the Dropbox desktop client never uses the client modified time at all (though it does set it so it matches the local filesystem).

I suppose the downside of using the rev is that you have to keep track locally of what the rev of each file was the last time you uploaded/downloaded, but this is a small bit of information to track per file and helps avoid correctness issues with your syncing (that could lead to data loss).

hemancuso

Thanks Steve -

Revs are great, but don't really speak to the issue. It's not so much that we're trying to use mtime in order to figure out what needs to be sync'd, but so that we can provide a network filesystem representation of Dropbox. And like the desktop client, we'd like to have the client modified time stay the same on a particular file when they move it into Dropbox via ExpanDrive.

If a user wants to migrate a large tree of info into Dropbox via ExpanDrive, all of metadata gets tossed. Most of that isn't particularly important, but users do notice when the modification times of data change.

Also, the use-case where some automated process [backup app, let's say] wants to sync data into Dropbox via ExpanDrive - those tools [rsync, et al] rely on the mtime as an indication of whether or not something has changed.

Right now the best we can do is keep a local database that maps a particular rev to some metadata, and then potentially sync that out. But given that the Dropbox desktop client can set mtime, it'd be nice to expose that to us [at least as an optional parameter on upload, if not its own metadata update endpoint]. Google Drive and Box already provide fairly robust metadata handling in their APIs, it'd be nice if Dropbox would consider it.

Steve M.

That makes sense; thanks. This is something being actively considered.

Anton Schegg

I also vote for this. I tried implementing a service to mirror a specific dropbox folder some years ago with api v1 and as a realized that I can't set the date at the dropbox side I've canceled the project.