I recently had to unshare a folder on my laptop so that I could rename the share. However, when I unshared the folder, Dropbox went through a long sync process (several hours) on my machine. When it finally finished, I saw that Dropbox had reset the "File Created Date" to today's date on all 270,000 of my files in this folder.
The file-creation date is important metadata for files in a file system. It is used to search for files by creation date, sort files based on the order they were created, and identify copies vs. originals. It must be preserved by any software that is performing backup/restore operations.
However, Dropbox does not preserve this metadata during various operations. For example, it does not preserve this date when restoring files on a new machine. Dropbox's explanation for this is that it's a "copy" of the file rather than a "clone" of the file. However, Dropbox is positioning this product as both a file sharing and a backup/restore solution. So this metadata *must* be preserved in a backup/restore scenario. It is a clear misrepresentation of your product as a backup/restore solution to do otherwise.
Moreover, deleting this metadata while simply unsharing a folder is much worse. Please note that I did not copy, restore, or even move these files. Rather, I simply unshared the folder and Dropbox overwrote the Date File Created metadata with today's date. So, once again, I've lost all of this metadata and I have to restore these files from a "real" backup/restore solution. This has cost me several hours of time -- again.
This is completely unacceptable. There are numerous complaints in your support forum about these types of issues. However, your technical support team appears unwilling to do anything about it. In addition, Dropbox keeps adding an assortment of low-value features that I don't actually need, while the core value proposition of your product continues to deteriorate.
Dropbox is one more incident (like this) away from begin dropped by me, my company, and all of my vendors and clients as our file-sharing solution. I say this to you with absolute sincerity -- please fix this issue or you will lose me as a client.
Hey @renze1577; thanks so much for taking the time to share your thoughts on this.
I just wanted to note that this is indeed expected behavior since you're practically changing your files' attributes while un-sharing them. Due to how syncing works, in this case, also changing the metadata of the files.
Syncing, which is one of our core features, is not to be confused with our computer backup feature or other 3rd party backup software.
If you'd like to suggest a change on either of those features, you can post your thoughts on the Share an Idea section of our Community so other users can back you up by upvoting your idea.
I know this is not much, but I sure hope it helps to some extent.
Please let me know if you have anything else to add or ask!
Thanks for providing your perspective on this issue. I really appreciate your input and clarification.
After reading your reply, I understand now that Dropbox considers its backup-and-restore functionality to be a separate feature from its file-syncing functionality. This makes sense to me now; however, I still think it seems potentially confusing for your users.
Regarding your point about this being expected behavior, I'm very interested in learning more to better understand Dropbox's position on this issue. So, if you're willing to help me to understand, could you please answer the following question: Why does Dropbox's "Unshare" operation change the file-creation date on all previously shared files? Why is this the expected behavior?
As a user, it seems odd to me that I would expect that the Unshare operation will change the file-creation date of all of my shared files? Essentially, what is Dropbox's rationale for doing so as opposed to simply preserving the file's creation date when unsharing files? It seems like it would be more work for Dropbox to change this file-creation date than to simply leave it as it was when the file was shared.
Also, to clarify, the files were created on my machine, shared from my machine, and then unshared from my machine. These weren't copies of files on a remote machine, these were the original files that were created by me, on my machine, on the date specified by the original file-creation date.
Ultimately, why would a user expect Dropbox to change the file's creation date during an unshare operation? This behavior appears to violate the Principle of Least Astonishment.
As a side note, I took your advice and suggested this feature in the Share an Idea section of the Dropbox community forum.
Thanks again for all of your help. I look forward to hearing your response!
Well, we know it can be hard to keep up good habits, so we made a new working from home cheat sheet, with some good habits, some things to avoid and some tips for making your day a little easier. Check it out here.
Work Smarter with Dropbox
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.