FYI: ISSUES SYMLINKS
1) If the symlink in inside dropbox pointing to another location then when a file is accessed this is resolved to the true location, and if tyhe file is then updated the operating system notifies interested applications that a file has been updated at trhe location it reolved to (the true location), if that is outside ofd the dropbox folder then DB does not know the file was updated so takes no action, on a DB restart the change is spotted as the application makes a quick pass over all files looking for changes from the database values. No content is checked just file meta data (date time size etc)
2) If the Symlink does not exist on a syncing machine, say it was just generated or was just renamed, then dropbox sees the symlink folder as a new folder and instructs syncing machine to make a new folder and not a symlink
3) recusive symlinks where it points to a location above it or another location that a symlink there points to a location above the first.
THERE IS NO ISSUE WITH SYMLINKS POINTING INTO THE DROIPBOX FOLDER.
When these are used they are resolved to the location of the dropbox and accessed normally.
* Many years ago there was a dropbox symlink app, it found symlinks in dropbox, resolved where they went to and then it monitored all the files at those locations for changes, when one was detected, it tweaked the symlink in the dropbox folder so dropbox thought the symlink updated, and the DB app then looked over the content of the symlinked folders for changes. This was OK unless the resolved location housed 10,000's of files then each change cuased DB to rescane all of them since it was only woken about the symlink location (I expect it is not possible to issue change notifications to sysmlink downstream locations as they are always resolved first.)
@Shawn B.14 wrote:
I'm torn between two theories, one of which touches on yours:
1) it isnt this thats an edge case at best
2) the issue is not the DB server back end sync
3) Dropbox choose to replace the meta detail data base on the files
C:\Users\[username]\AppData\Local\Dropbox\instance1 used to contain some big files containing all the meta data, now a folder C:\Users\[username]\AppData\Local\Dropbox\instance1\sync has appeared that contains it.
They chose to not migrate the database but to build it from scratch, I know this as my near 10GB signature file has vanished and a new one is being built with a new name.
However (A) that means it stuck doing a full resync on the 500K+ of files I have and (B) the the full resync on thayt sizze file set CRASHES THE DROPBOX APP. (C) even if it did not crash my resync time is counted in days to weeks and the result of that is unsynced machines and machines that end up with plenty of conflicts on each and every file changed elsewhere and not yet reindexed locally, as the result will be a conflicted copy.
Yeah no worries. I discovered it by accident .. something resting on my space bar ...
Mine seems to of indexed about 2-3000 files over the last week .. which I suppose is progress.
Question to the forum about Symlinks .. I've never knowingly created one .. does dropbox do it itself? When, for example, you migrate it to a different hard drive?
@PatWard the Dropbox desktop app doesn't have the ability to create symlinks for your files.
However, if your Dropbox folder was renamed, the Dropbox desktop app will create a hidden folder with the old folder name ("Dropbox"). This is called a “symlink.” This hidden folder points to the new Dropbox folder from the old location path.
If your computer is set to show hidden files and folders, this symlink may look like a secondary Dropbox folder on your computer but it isn't.
Notes for hidden symlink folders.
You can mention me, or other Dropboxers and we will be happy to participate in your discussion more.
Community Moderator @ Dropbox
Did this post help you? If so, please give it a Like below.
Did this post fix your issue/answer your question? If so please press the 'Accept as Solution' button to help others find it.
Still stuck? Ask me a question! (Questions asked in the community will likely receive an answer within 4 hours!)
I switched from Google Drive to Dropbox 16 months ago, because Google Drive maxed out my CPU, duplicated folders and files, took forever to scroll files, and more. The particulars are at https://www.quora.com/Why-is-Google-Drive-so-slow-for-downloading-and-uploading
Dropbox was a breath of fresh air. Low CPU use, fast uploads and downloads, fast indexing, fast scrolling through many files online. I was very happy to pay double the cost per terabyte at the time.
Now, I wonder if Dropbox is starting to move away from developing smaller-scale online backup like Google Drive did. If so, from a few decades' experience with software, the only solution I know of would be to move to a new company who wants new customers needing good backup solutions.
FOR Anyone witrh the NEW relase that is now STUCK syncing/restarting/limbo
OK what appears is the database DB uses to monitor your files was "updated" and the process requires a reindex. For reasons unknown thios doesnt seem to work anywhere near well enough.
Here was my solution to get around it.
1) UNLINK the PC, restart
2) rename the DROPBOX folder OLDBOX
3) LINK the PC, during signup, select to selectively sync NOTHING!
4) Once upto date (with no files present), change your settings to what they used to be, like save space settings etc, and apply
5) Once upto date (should be near instant), change the selective sync to what it used to be, and apply.
6) shutdown the DB app
7) move the content of the saved folder OLDBOX over top the the current dropbox content
start the DB app again
9) await it to sync/check/update (takes a while but is a **bleep** load faster now)
Its STEP 5 that I think helps, when you have cloud only files I expect you get all the reindex data sent to you from the dropbox servers as you dont have the files so cant reindex them. Then when you replace those with the original files and restart the app, it sees a real file and compares the content to the index data, and finds it the same so moves on. This appears alot quicker than reindexing the original files and then comparing it to the dropbox servers index data, its likely just a timing or bulk activity thing, that you get sent all the index data at once when you change the selective sync rather than fetching it yourself form the file then comparing that to the servers one file at a time.
I just got a server with 2+TB in 700k+ of files back up.
While it was processing a few files were updated rempotely and the syustem dealt with them as they appeared, likely on a sperate execution thread.
Hope this helps someone at least!
I'm starting to wonder if this is a memory adressing bug.
The DropBox app is listed as a 32 bit app on Windows 10 and I've noticed that while 'Starting...' or, if I'm lucky and get to 'Syncing...', the memory usage climbs up and up until it gets to the high 3GBs.
A 32 bit app can't address more than 4GB of memory as I undertand it so I'm curious if the crashing happens as the OS attempts to allocate more memory than the DB APP can actually handle.
Just my thoughts.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.