Child Item

Stable Build 161.4.4923

Thanks for using Dropbox! The desktop client is regularly updated with many improvements and fixes including the following:

Features in this update:

Closing the sign-in dialogue while not signed into any account will now exit the application instead of leaving it running in the background.

Fixes in this update:

A bug preventing some Dropbox Backup users from seeing filename issues in the sync errors window has been resolved.
The Copy link search bar functionality in the taskbar (Windows) and menu bar (Mac) has been fixed.
Issues preventing icons for files with no extensions from appearing in sync history and the share modal have been resolved.
Users on a manual proxy will now be directed to log in through their web browser, not the setup wizard.
Issues preventing Git from working correctly in Dropbox for some Mac users have been resolved.

Download

Windows	Standard Installer	Offline Installer (32 Bit) Offline Installer (64 Bit)
Mac OS X	Standard Installer (Universal)	Offline Installer (Intel) Offline Installer (Apple Silicon)
Linux	x86_64 Offline Installer	x86 Offline Installer

Auto-updates: In progress

Find more posts tagged with

Desktop

Stable Build

Insightful

Comments

Здравко

🤦 Ok, seems nobody from developers takes care for the bugs reported. 🤷 That's not some secret, but... anyway.

Geoe

Their help team are ineffectual and only try to upsell you. Once my 2T contract runs out I am going elsewhere.

Not that they will care.

Megan

Hey @Здравко, I hope you're doing well!

I'd be more than happy to send you an email, in order for us to have a closer look into this, and provide any further info or help that you may need. Would that be okay?

Keep me posted!

Здравко

@Megan wrote:
...
I'd be more than happy to send you an email, in order for us to have a closer look into this, and provide any further info or help that you may need. Would that be okay?
...

Hi @Megan,

Nice you are taking care. 🙂 I don't need help with the application! I have signaled for a bug in your application multiple times (actually initial signal comes not from me). You can see here, here, and here (if you want, of course). The problem is discussed in details (even some workaround has been provided); I'm not sure I can add something more, but if your developers cannot reproduce it I'm ready to assist. The main problem (as many users many times denoted) is absence of any care from developers related to reported bug which lasts for 3 release already (till the moment of this post). You can help (probably) as reminding for this to your coders (while they don't hear me).

Thank you.

Megan

Hi @Здравко!

I can definitely see where you're coming from. Keep in mind, that I suggested the ticket route because we need the device specific info to investigate fully and troubleshoot directly with the advanced team on the ticket.

If you change your mind, I am always here.

Здравко

Hi again @Megan,

As I said:

@Здравко wrote:
... I'm ready to assist. ...

Did you try it? Do you have any questions related to reproducing the issues? There is NOT anything "device specific"...

ADD: Some additional information if someone developer decides to take a look on discussed issue.

All files in Dropbox have attribute "com.dropbox.attrs" (extended attribute actually). The files having only this attribute don't meet any sync issues. Some files have in addition 2 more attributes - "com.dropbox.apple.FinderInfo" and "com.dropbox.apple.ResourceFork". All files caring 3 attributes refuse to sync. Even more, seems files are able download successful in "Dropbox/.dropbox.cache/new_files" (with encoded names) and attributes set. At that moment something confuses the application and instead moving the files (and rename) to the actual place in Dropbox folder (as can be expected and performed for most files) the application deletes them and start new try to download again - in loop; a loop that never ends.

Correction: For some files the loop never ends, but for others - after 2 checks for non existing attribute "com.dropbox.placeholder" the files are just removed and no more tries. This attribute has never been set. So why is the application looking for something certainly nonexistent (and seems the sync breaks after the unsuccessful search)? 🤷