Chipping in as well. I'm a long term Dropbox user personally and am deploying Dropbox for Business in a corporate environment. Maintaining the (restored) original file's metadata is critical for dropbox users who are using its service for shared work, such as ensuring that the data integrity of a file remains untouched, unedited. For the average user, it is a checkpoint for them to acknowledge that the file remains as-is, per the last user authorized edit. Restoration is one important feature that separates Dropbox from other cloud storage services and this is causing a lot of distress and duress. Users simply don't have a peace of mind and are even doubting if the file restored is back in the same piece as they know it. I implore the Dropbox team to seriously go back to the drawing board and restore this!
Well, time passes by and Dropbox programmers seem to completely ignore this important dealbreaker.
As it should be clear even to them that the decision to NOT retain the original dates in restored files is NOT LIKED by anyone, and is instead a REAL PROBLEM for a lot of professional and home users, I think that if they still did not turn back to old file restore behaviour is because they CAN'T.
I fear that this was not a change, but the result of a problem, and a serious one: maybe Dropbox simply LOST all metadata in old versions of stored files, so that they are now UNABLE to let us restore an older version of a file with the correct date and metadata.
As keeping old versions of files is a PAID feature of Dropbox, this is really a BIG issue.
Could someone PLEASE confirm this, so we can migrate to another syncing solution, or deny it and return to old restoring behaviour?
Thanks in advance
Agreed, it is hard to imagine anyone thinking this change was a good idea. I was quite shocked at the time it took for Dropbox to even acknowledge the behaviour on my original post. They spent far more time trying to get me to validate my email. Let alone any recognition of the obvious problems it causes. I have always paid extra for keeping versions longer. Maybe this change is a result of rolling out a keep versions feature for everyone. The original date is part of the file, if they change it then they are modifying the file. I suspect also that is is the result of some other change that they are unable or unwilling to undo. Surely nobody could be stupid enough to set this in motion deliberately. I've been relying on Dropbox for years and the safety net that it provides. As it stands the issue is bad, but if I ever have to restore a larger number of files it would be disaster. I feel this is endemic of a deeper problem at Dropbox and has reached the point where I am actively looking at other solutions.
PS Now they have added this feature, so all the files this shifts off your drive to the cloud are irreparably damaged…
World-class sync technology—move out-of-date files off your computer’s hard drive and to the cloud with Dropbox Smart Sync.
Another person affected by this insane change of behaviour - this issue urgenty requires escalation. However, I have a specific question not yet addressed.
A vital and large folder of mine self-deleted. I'm 99.9% positive I did not do this, so this is another (major) issue. Fortunately, Restore got the files back. I am hopeful - not certain, will have to check at the day's end - that I have another system offline when this false deletion took place. If I start up this system unconnected to the net, I can make a local copy with all the correct timestamps in place. Is there a procedure by which I can then replace the faulty restored time stamps with my local copy?
I thought I was going crazy. This is insane! I kept restoring a particular C source file and noticed the file date Windows Explorer was apparently not changing. The restored file should have a file date of March 28 2019, not today, July 8, 2019. Attempted the restore function 3 times and finally, I had this horrible suspicion that this could be something done by Dropbox. Sure enough! The definition of the word "RESTORE" means to put the file back exactly as it was. The updated Restore function now completely removes our abilty to know when a source file has been modified! What horribly inept person dreamed up this change? Worse, I can't believe a team would approve it! I know there are better tools for source managment, but good grief! I need to look for a new cloud provider. This has to go down as one of worst decisions ever by a technical services provider.
So my short-term solution is to find another service and maybe run in parallel with DB. I don't want to make a move until I learn a bit more about what I might be missing other than the speed that comes with DB's block-level file management. Sounds like OneDrive only supports block-level on MS file types. My sense is that there is a patent that prevents anyone else from using this. So far, I have tried Google's Backup/Sync client for Windows. It doesn't restore files to a folder, it just allows you to download them, and the file's metadata gets messed up in that process too. Sigh. Will try some other services when I get time. OneDrive won't work easily as a parallel solution since it won't allow you to choose a local drive folder to sync with. It has its own path. Anybody else have ideas?
I am in the same boat. Due to a "perfect storm", I will not go into, over 65,000 files were deleted by one of my team members. Unbeknownst to me I merrily restored the data patting myself on the back for having the foresight to subscribe to PackRat years ago.
Well guess what I now have 65,000 files all with the exact same create date. Whoever thinks this is a feature come on over and try sorting this mess out!!
I know someone is going to say why did you not look sooner at the create dates, and they would be right, but in my haste to get the system back before my team in a different time zone woke up I ran with it. Well frustratingly it turns out there was no other solution anyway.
Once I discovered the problem I contacted Dropbox for a solution and was told they could do a roll-back and I would get my account back. Like a time machine the account would look exactly like it did on that date. They walked me thru the process and I though great. Oh no no no! Two different agents proclaimed I would get my files back with the correct create date but that is not what happens. Dropbox resets the create date as of the day the rollback takes effect - much like me doing a restore. So, a big waste of time and compounded the horrible confusion surrounding me.
I am so pissed with how cavilier Dropbox acts about this issue. Do you know what thes suggested as a solution to Dropbox changing the create date - go to each and every file and manually change the dates back to what they were! Assuming I had the patience to do this where exactly do they tihink I am going to find the correct create date?
There is a whole lot more complexity and depth to this story with some really stupid mistakes on my part and on the agents advising me but needless to say the end result of all this is I still have 65K files with the wrong date. I am now scouring old computers looking for the files in the hope I can find some before this debacle happened.
Its a cautionary tale to others - both restoring and rolling-back your account changes the files ceate dates. Be forewarned.
Oh no. This what happened to me yesterday, Dropbox did some kind of autosync (which is totally unexplained, it deleted itself of several pcs and this seems to have been the issue. We lost thousands of files and numerous directories. We have tried to restore and they all are now dated 22/07/2019. This is a total disaster. We now cannot delete old files, we cannot find files. It useless to us.
Did you subscribe to Dropbox's backup service? When I signed up it was called Packrat.
The one good thing is Packrat will show you the version history. Then using an app you can change the create date back to what it was. Annoying and time consuming, but this what I have resorted to for the 65,000 files I lost.
I am only fixing key file sets and leaving the rest as restored and accepting I lost the create date. However, because I have Packrat I can always go and check if I needed it far a particular file. So its been a handy tool in the aftermath of this stupid Dropbox bug.
If you don't have this then your only hope is to find an off-line computer that was synched to Dropbox and copy those files to a NEW directory. Do not bother to overwrite the restored files because this will not work - the older files are of course "older" so will not copy. There is a whoe process I have learned how to handle this nighmare.
If you need more help you can log a ticket with our Support Team here (expected response time 24 hours), or contact us on Twitter or Facebook.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!
Solved! : See solution