I just got done syncing my Dropbox with odrive and found that all of my files were not only touched affecting the “date added” value, but the “Date Modified” value was updated as well even though the files were not changed at all. While I understand that directories are going to be created new and have new dates, it is most disconcerting that file metadata is tainted by odrive in that it doesn’t preserve the last modified dates for files that are synced. What appears to be the happening is whenever a file is considered “moved” (which may not mean that the file actually moved), but some conditions might indicate otherwise, the file modification date is updated as if to indicate there was a file change when in fact there wasn’t. This defeats the purpose of syncing as syncing relies on the modification dates to be accurate in order for it to work. Otherwise, file churn will be constant.
If someone has an explanation as to what conditions cause the modification date to be updated on a sync that would be helpful. Of course it is possible that I did something that inadvertently caused this that I can avoid down the road, but the fact that all of my Dropbox files think they were just modified over the past 24 hours as they were synced is very bothersome. I lose some key historical data about the files using the odrive which is not acceptable.
More specifics: the files that had their “last modified” date changed were in a directory that got renamed. This should definitely NOT affect “last modified” date of the file. Again, this pretty much constitutes a data loss as I now don’t know when the last time the files were edited. Some of them hadn’t been changed in years. If this is how odrive behaves, then I cannot use this tool and you guys should really fix this!
Hi @DarfNader,
Amazon Drive doesn’t have a concept of “Date Modified”, which is why they don’t list it on their web client. odrive tries to implement its own modtime using a custom metadata field in the file metadata. It works well, but only odrive can read from it and use it.
Setting this additional field is a secondary action in the upload process and is not considered a “requirement” for successful upload, so it is possible for that action to fail and the file to be uploaded to Amazon anyway. In this case the file will not have the custom parameter and the modtime will be seen as the upload time when you download the file again.
Renaming a folder should not affect the modtime of the files inside. I just ran a few tests here to confirm. Even if the files were re-uploaded, for some reason, odrive will still try to send the modtime as seen on the filesystem, if possible.
Can you tell me what you are looking at when viewing these times and provide some additional details on the rename action?
This was in Dropbox. For some reason, it appears that the version history has been wiped for these files as well. I am trying to figure out what happened and when.
Sorry, I thought you were talking about uploading your Dropbox content to odrive. I understand now.
Modtime setting is unavailable in our current Dropbox integration, as the API did not support it. Their newer API does support it, however, and we plan to move to that within the next few months.
YOU DON"T SUPPORT IT? This product is far from ready for market. First your B2 integration is read only and now your DropBox implementation is basically worthless because you don’t preserve the metadata.
How do I go about getting my money back so I can go get a product that is actually finished?
For clarity, the Dropbox API doesn’t support it, so there is no way to set it with that API. Their V2 API does support it, and we will be implementing a new integration to that API within the next few months, replacing the current integration against their V1 API.
For B2, until recently their hashing flow prevented us from full integration. More on that here: B2 (Backblaze) upload
Within the last couple of weeks B2 made the changes necessary to fully integrate.
B2 has had their API updated for several months now, yes? Your competitors seem to be able to support it, though I admit most products in this space are pretty terrible. I really was hoping this one would be different.
As for Dropbox, they released their v2 API on 11/4/16. That’s over 4 months ago! I would imagine that being an integrator you were giving their SDK even before that. I don’t know what your resources are, but if you can’t turn around support for a new API in 4 months when it’s the most popular cloud storage product on the market, I have serious doubts that odrive is in touch with basic needs of a file synchronization tool. Then again, Dropbox was not doing much better by being unable to support the preservation of file metadata until late 2016- 10 years after they launched. Honestly, it seems like every single cloud storage provider has some fatal flaw that makes it unusable to anyone except amateur users who don’t understand the implications of a cloud provider that doesn’t preserve file metadata, which sadly is most of them.
What about your encrypted volume product? Will files written to an “encrypted drive” have their metadata preserved or are they also at the mercy of the the antiquated API you use for the provider?
Their “hash at the end” fix came out within the last couple of weeks (late Feb, 2017), as I said above.
Integration work is not trivial. We have suspended new integrations (which is what Dropbox V2 and the 2nd iteration of B2 would be) since we are undergoing a large-scale development effort on the existing features and core functionality.
The current Dropbox API works well, within the confines of what is allowed, and is found to be exceedingly usable by most of our users. I apologize that that this limitation of their API does not work for your use cases.
Everything we do is at the mercy of the APIs used for integration. Sometimes we can find workarounds, like we did for Amazon Drive.