We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
In a "mdworker quit unexpectedly" loop after turning on Smart Sync
Ever since turning on Dropbox Smart Sync, Spotlight has been going nuts and using tons of CPU. The helper app "mdworker" is constantly crashing. Will report back after Dropbox finishes indexing all t...
Hi everyone,
I wanted to give you an update on the issue of mdworker crashing when reading a mismatch in the expected logical vs physical size of PDFs on Mac.
Firstly we've not forgotten about this, a lot of work has been going on in the background to resolve the issue. It has required extensive code re-writing. For those not familiar with the issue, users may see within the logs mdworker crashing. This crash is fairly silent, though will appear in logs. There's no risk to data, but for those who like to inspect clean logs this can cause a lot of noise and may be viewed as sub-optimal.
Based on the feedback raised by yourselves on this forum we've spent considerable time working toward a fix. We've changed the way we write Smart Sync placeholders (ie the files that look like files, but take up 0kb until recalled) for those on 10.13.5 and later. The new sparse format will not trigger an mdworker crash.
We've tested within the beta to validate the code and at this point have now rolled the fix / changed behavior out to 100%.
This is a forward fix, so from now on all and any placeholders created will not suffer this issue. For those who have the placeholders (the empty files with the grey cloud symbol on them) already on their machines there are a few options:
- Unlink and relink your Dropbox. Note: this will trigger a reindex of content that may take minutes to a few hours depending on your filecount.
- Remove the content, via Selective Sync, then return it. Similarly, but perhaps preferably, this will remove the placeholders then re-add them quickly and non-destructively.
There are a few other options, but those keen to avoid this error being highlighted in logs can take these steps.
Many thanks for your feedback on this issue here, it's driven a clear change in product. We pay close attention to the feedback surfaced via this channel so if you have other wishes please either add to existing threads, up-vote ideas, or create your own thread to spark discussion or development.
Ross_S
Dropbox Staff
Dropbox StaffActually mdworker crashing is due to the way apple interacts with certain filetypes.
The issue is only present on HFS file systems, so, with the introduction of spares files on High Sierra - which uses APFS - this issue is resolved.
For context, firstly, while you see the errors within event log there are no issues with the functionality or operation of your Dropbox software. These errors do not indicate an issue with the saving of your data.
What you are seeing is mdworker crashing as, when it reads the logical size of PDFs, the actual size and past size differ, causing the issue. As mentioned on the forum thread you could disable it/Spotlight but we would certainly not recommend this. While the error may look noisy in the logs there is no actual issue here.
Hope this helps!
I'm using 10.13.5 on APFS and having the issue. So any insight on how to fix it would be greatly appreciated.
- Ross_S
Ah, the change we made to leverage sparse files introduced in APFS hasn't landed in the public facing build yet.
Sorry about my over-eagerness there.
The change will make it into the stable build in due course, we just need to complete testing on it.
I'll post an update once it does, so, at this point, let me just correct my original statment and advise that we are currently working on this issue.
Thanks and appologies for that.
Just today I discovered I seem to have the same issue -- only in my case the consequences are much more dire. When mdworker chokes on a font or PDF that has been SmartSynced, it crashes my machine. I must have had 30 crashes in the last two days. This only seemed to start after I upgraded to 10.13.5.
That said, I have Dropbox synced to an external (HFS) drive because my internal drive can't handle the size of our Dropbox, and I know using external drives is not supported. But yeesh. SmartSync has been a big bag of hurt for our team.
Edit: I am not actually sure that the machine crash is linked to this bug at all.
Thanks Ross!
Looking forward to this update in hopes it resolves - would it be reasonable to expect it by the end of July 2018?
I administrate over 20 Mac laptops all with various configuations but they all have in common the Sierra / High Sierra + Adobe CC + Dropbox + Office 2016.
Only 1 of them is having this issue after upgrading to Sierra.
The issue followed to a new machine in which the users profile was moved over with the migration utility.
If I were to do a fresh install of the OS, along with a fresh install of all software, then enable sync - I would expect it to work, since I've got a lot of other machines working just fine. If it did not work, I would suspect something strange with this specific users dropbox account profile (or other 'external' factor) which is tickling their sync'd files in some inapprpriate way.
Update:
I obtained a new machine for the impacted individual. Erased the HD and then Reinstalled High Sierra.
I copied her profile over and the 'mdworker' issue persisted.
I then erased the HD again, reinstalled high sierra, then performed a fresh install of all the needed applications - including dropbox, Adobe CC, MS Office, etc and then had the user reset all of their preference settings, etc.
The mdworker issue has not resurfaced.
The point being that this is clearly an issue on the client and persists across an OSX profile data migration and is not anything inside the dropbox cloud (e.g. corrupted files) causing the issue.
K
We have similar issues with the mdworker looping and quitting on dropbox. Any update to the release of the patch?
Thanks,
Gabby
