Happy Friday! We've got a new release for you in the 3.8 series!
Auto-updates: In progress
**Edit: There is a newer stable build than this one.**
This new version 3.8.8 appears to have fixed issues that I was having & is working ok so far on my PC.
Until now I had only been able to use 3.6.9, and not 3.8.5, 3.8.6 etc, as my Windows XP SP3 AMD Athlon PC was not able to connect on those other 3.8.x versions & dropbox was not working at all - version 3.6.9 was the latest working version for me prior to this new 3.8.8, which now seems to have fixed those issues for me.
Please can you get the dev's to check the code? I've found that I cannot have Crashplan and Dropbox running at the same time. When Dropbox starts, at some point Crashplan fails (usually pretty quickly). If I leave Dropbox off, Crashplan has no problem. So seems to be a conflict somewhere? That's Crashplan's cloud backup storage, not local backup storage.
I downloaded the offline installer for 3.8.8 and Dropbox stays stuck in starting mode.
Just a though, since Windows 10 is so green, maybe treat it separately, don't bundle it with the other Windows products. I suspect that's also an issue (Windows 10 is best for those who want integrated services). Also given how Windows 10 changes how it treats network connectivity, maybe it needs kid gloves?
Finally, while not directed personally at you, I'm getting close to leaving Dropbox (and blogging about the reasons why, as well as emailing all my contacts and clients about the issues). Since that initial upgrade, it's been broken (the sad part, all was working fine, and there was no reason to upgrade). Even when going back to 3.6.9 ( I think I was at an earlier version, but don't remember which one (hence why it should not have been updated... If something ain't broke, don't fuss with it), it won't work anymore. What's worse, the odd time 3.6.9 managed to connect, it wanted to sync 700k+ files - That's not realistic. The most newest files, that would be on the desktop and not Dropbox (and visa versa), those files should upload/download first! (That's just common sense). The rest of the files are not changed and therefore should simply be compared for differences, and if different, synced in the background. Last month (July) my yearly renewal of 200 bucks was regretfully paid (I've been a paying client for 4 or 5 years now). Given that Dropbox is charging a premium compared to many competitors, I really feel that Dropbox is now providing me substandard services. I really should request a refund (minus the July and August cost). I'm quickly reaching the end of the rope.
Sorry about the issues you are experiencing. Have you given the experimental build a try?
Roger, while I don't use CrashPlan, what may be happening here is that something (possibly CrashPlan, possibly not) may be modifying extended attributes or otherwise touching files in a way that modifies the file without changing the contents. This causes Dropbox to appear to be synchronizing, while in reality nothing really gets uploaded or downloaded.
You can cause a similar behaviour by setting or removing certain NTFS attributes (compression, for example).
If this is the case, it normally resolves itself fairly quickly (compared to doing a full re-sync, anyway), but in the mean time, large numbers of files may appear to be uploading or downloading, while if you watch your network traffic, you'll see that the files aren't actually being transferred. And "resolves itself fairly quickly" only applies if whatever is causing the issue stops.
You might want to use something like SysInternal's Process Explorer to see if anything other than Dropbox is accessing/modifying Dropbox files while Dropbox is running. If you can identify exactly what is happening, it might either help you to work around it, or help Dropbox (and/or the other application) interact better.
Still crashes for me, just like 3.8.5/3.8.6 -- I don't know exactly when I started experiencing problems, but definitely had them with those versions. Pretty much crashes within 10 minutes of my system booting up. Crash information:
Windows 7 Home x64
Problem Event Name: APPCRASH
Application Name: Dropbox.exe
Application Version: 184.108.40.206
Application Timestamp: 55c19e38
Fault Module Name: MSVCR120.dll
Fault Module Version: 12.0.21005.1
Fault Module Timestamp: 524f7ce6
Exception Code: c0000005
Exception Offset: 0000f8c5
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Roger, I have crashplan and DB working fine together. I have a lot of files so I did have to change the ini file in crashplan to allocate more memory to it. Before I did that, it would crash. Did you try that? Here is a link to give it a try.
I've just downloaded this version to try since today my standard Dropbox installation crashes some one-two minutes after startup (worked fine up to yesterday). Unfortunately this version is also crashing in the same way.
Faulting application name: Dropbox.exe, version: 220.127.116.11, time stamp: 0x55c19e38
Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp: 0x524f7ce6
Exception code: 0xc0000005
Fault offset: 0x0000f608
Faulting process id: 0x11ec
Faulting application start time: 0x01d0d8ba08374886
Faulting application path: C:\Program Files (x86)\Dropbox\Client\Dropbox.exe
Faulting module path: C:\Program Files (x86)\Dropbox\Client\MSVCR120.dll
Report Id: 77a0cef5-44ad-11e5-8fb4-402cf4893b70
Since I have VS2013 installed I've attached a debugger and it seems that the application is trying to write to address 0 via memcpy. I am not a C/C++ developer but it seems that the problem could be some sort of memory allocation issues (memory freed before it was used?)
Unfortunately in the debugger I can not see the stack since it tells me that stack frames are incorrect or missing.
Here is the stack trace
msvcr120.dll!memcpy(unsigned char * dst, unsigned char * src, unsigned long count) Line 305 Unknown
[Frames below may be incorrect and/or missing]
I can not tell which method could be causing the issue. Here is the real exception message:
Unhandled exception at 0x6E22F608 (msvcr120.dll) in Dropbox.exe: 0xC0000005: Access violation writing location 0x00000000.
Perhaps if I had a debug build with full symbol information I might be able to have more insight into what is going on.