Child Item

Partial file update

Hello,

Is there some available way to update (not entire upload) a file?

Let's assume some 100MB file and has to be updated only 1kB starting on positon 1MB. Is there a convenient way this to be done without need to download entire file, update it locally, and finally upload it back? I can't find such in API documentation. Currently, that's a complete resources lost (both time and traffic), especially if some small part of a big file have to be updated relatively often!

Thanks.

Find more posts tagged with

Developers

Comments

tahsini

We currently do not have a feature available in the API for this. I have filed this as a feature request, but I can't promise if or when this would be implemented.

Здравко

While talking for missing features that have to be added, let's mention missing adequate API dedicated for serialization. Currently something similar tends to be "2/files/lock_file_batch" and "2/files/unlock_file_batch". While previous API calls are usable to serialize user (human) work, the same calls can't be used for application serialization! If an application have to update particular content continuously and monitor changes, coming from another instance (running on other device owned by the same user or shared to somebody else),... 🧐 How can this get done?! - actually to be ensured multi device system stability! 🤔 I can't see such right now.

Exact implementation gonna depends on the underlying storage engine in all cases. But in all cases a new call scheme should become available! To be stable, lock has to be driven by a single connection and if for some reason connection breaks by accident, short time after that (a few seconds, for example) the lock has to get released automatic to lets access by others. 👆 Just an idea deserving attention.

Sam S.6

Partial updates would indeed be a very useful feature! After all, this is what the Dropbox client itself is doing.

Greg-DB

Thanks for the additional feedback!

@Здравко For information on detecting changes I recommend reading the Detecting Changes Guide, if you haven't already. Also, for reference, Dropbox does enforce an automatic system of short-term locking that prevents simultaneous changes. You can find more information on that under the "Too Many Writes" section in the Performance Guide. It sounds like you may want something like that where you can control that from your own code though, so I'll pass that along as a feature request.

Здравко

Hi @Greg-DB,

Seems, my example gets misunderstood. In the example changes detection is just a example part, not a final target! I'm aware how a change could be detected. Problem arise when multiple changes could happen in same time. Changes detection can't be used for conflicts avoid in such cases. I have no idea how this could be achieved using the available API features. Again, changes detection is just a part from the example (maybe far from perfect example, rather confusing, seems). In the referred performance guide, you mentioned, is nothing related to serialization!? Serialization is main concern, not the writes count! Is there stable way I can use to "flag" something and perform some sequence of operations without worry about performing the same operations set from another application instance could make a mess? Seems the "short-term locking", you are talking about, tend to prevent underlying Dropbox storage possible damage (i.e. per single write step protection and serialization). What about set of API calls?!

My idea and proposal (on "green" of course, just idea) is to lock files in a way that the existing pair do, but applicability not restricted between different Dropbox account, but applicable per application instance accessing the same thing (whatever is) in same or different account. Also care should be made for possible network issues! Unlike human action serialization, which can call one call to lock something and another to unlock, application serialization have to be implemented in one call, so if some network break gets up, locked entry gets released automatically. Something like locking and unlocking be implemented in a single call (at the beginning and the end) and generally behaving similar to "longpull" call (waiting not for some change, but for last POST byte or net link break). While the previous call is on go, a protected set of other calls (selection of developer) could be performed parallel in a safe manner. In such a way stability is guaranteed.

Hope now my idea is a bit more clear.

Greg-DB

@Здравко Thanks for clarifying! The Dropbox API doesn't offer anything exactly like that, but we'll consider it a feature request.