Download

Auto-updates: In progress

---

bobas wrote:

...

• Linux 32-bit releases are now cross-compiled on 64-bit Linux 

---

Hi bobas,

What actually this mean?! 32-bit builds was always possible to be used in 64-bit environment. What is the new thing here? :thinking: Aah... You have just discovered that's possible. :wink: Congratulations! :slight_smile:

The 64-bit build still has issues opening submenus! :unamused:

---

 wrote:

...

• Linux 32-bit releases are now cross-compiled on 64-bit Linux 

---

Hi ,

What actually this mean?! 32-bit builds was always possible to be used in 64-bit environment. What is the new thing here? :thinking: Aah... You have just discovered that's possible. :wink: Congratulations! :slight_smile:

The 64-bit build still has issues opening submenus! :unamused:

Thanks for using Dropbox! Here are the user-visible changes in v89:

\n
• Updated text on Mac OS 10.15 Catalina consent dialog to increase clarity that Desktop directory access is required for screenshot upload feature. 
\n
• Fixed an accessibility issue so voice over now declares the correct number of rows for the member list in the sharing modal.
\n
• Linux 32-bit releases are now cross-compiled on 64-bit Linux 
\n

Thanks for using Dropbox! Here are the user-visible changes in v89:

\n
• Updated text on Mac OS 10.15 Catalina consent dialog to increase clarity that Desktop directory access is required for screenshot upload feature. 
\n
• Fixed an accessibility issue so voice over now declares the correct number of rows for the member list in the sharing modal.
\n
• Linux 32-bit releases are now cross-compiled on 64-bit Linux 
\n

This notice is about how we create builds when releasing them, not about running them.

Previously, we would use a 32-bit machine to compile the 32-bit Dropbox application.

Now we use a 64-bit  machine to compile the 32-bit Dropbox application.

There should be no regressions in functionality due to this, but, since the overall population of 32-bit users is small, we are unable to test every feature. This is a heads up so that users can tell us if they notice any problems.

Here is some more information about cross-compiling - https://stackoverflow.com/questions/897289/what-is-cross-compilation.

This notice is about how we create builds when releasing them, not about running them.

Previously, we would use a 32-bit machine to compile the 32-bit Dropbox application.

Now we use a 64-bit  machine to compile the 32-bit Dropbox application.

There should be no regressions in functionality due to this, but, since the overall population of 32-bit users is small, we are unable to test every feature. This is a heads up so that users can tell us if they notice any problems.

Here is some more information about cross-compiling - https://stackoverflow.com/questions/897289/what-is-cross-compilation.

Customers don't care how you compile your code or app. Customers pay you for features or services which you provide. It doesn't matter 32-bit or 64-bit they are using.

Hire more QA engineer or take away the 32-bit at all. Otherwise provide quality product. 

\"This notice is about how we create builds when releasing them, not about running them.\" - you should run them and test before you upload it on the production server. Or correct or return to the backup quickly. And what do we see \"Installing version 89.4.278 has not solved the \"Syncing...\" problem\"....

\"we are unable to test every feature\", \"users can tell us if they notice any problems\" - I hope you are not developing software for cars.

Customers don't care how you compile your code or app. Customers pay you for features or services which you provide. It doesn't matter 32-bit or 64-bit they are using.

Hire more QA engineer or take away the 32-bit at all. Otherwise provide quality product. 

\"This notice is about how we create builds when releasing them, not about running them.\" - you should run them and test before you upload it on the production server. Or correct or return to the backup quickly. And what do we see \"Installing version 89.4.278 has not solved the \"Syncing...\" problem\"....

\"we are unable to test every feature\", \"users can tell us if they notice any problems\" - I hope you are not developing software for cars.

---

nikhilm wrote:

This notice is about how we create builds when releasing them, not about running them.

Previously, we would use a 32-bit machine to compile the 32-bit Dropbox application.

Now we use a 64-bit  machine to compile the 32-bit Dropbox application.

There should be no regressions in functionality due to this, but, since the overall population of 32-bit users is small, we are unable to test every feature. This is a heads up so that users can tell us if they notice any problems.

Here is some more information about cross-compiling - https://stackoverflow.com/questions/897289/what-is-cross-compilation.

---

This explains why I'm having problems with 32-bit machines - you're not testing it on a 32-bit machine with files larger than 2GB so you don't see problems. I suspect it's linked to the maximum signed integer size on a 32-bit machine (2^31-1: https://en.wikipedia.org/wiki/2,147,483,647), and 2GB is one byte more than that.

---

 wrote:

This notice is about how we create builds when releasing them, not about running them.

Previously, we would use a 32-bit machine to compile the 32-bit Dropbox application.

Now we use a 64-bit  machine to compile the 32-bit Dropbox application.

There should be no regressions in functionality due to this, but, since the overall population of 32-bit users is small, we are unable to test every feature. This is a heads up so that users can tell us if they notice any problems.

Here is some more information about cross-compiling - https://stackoverflow.com/questions/897289/what-is-cross-compilation.

---

This explains why I'm having problems with 32-bit machines - you're not testing it on a 32-bit machine with files larger than 2GB so you don't see problems. I suspect it's linked to the maximum signed integer size on a 32-bit machine (2^31-1: https://en.wikipedia.org/wiki/2,147,483,647), and 2GB is one byte more than that.

I'm still experiencing the endless sync problem that everyone else started having from the update 2 weeks ago and discussed here: https://www.dropboxforum.com/t5/Files-folders/Dropbox-is-stuck-syncing-after-an-update-what-can-I-do/m-p/392086

I'm still experiencing the endless sync problem that everyone else started having from the update 2 weeks ago and discussed here: https://www.dropboxforum.com/t5/Files-folders/Dropbox-is-stuck-syncing-after-an-update-what-can-I-do/m-p/392086

Hi nikhilm,

I fully agree with Hexrby! \"Customers don't care how you compile your code or app. Customers pay you for features or services which you provide.\" Customers interest in working solutions and quality products! Yes, more QA is need, for everything. No for misbehaving (buggy) databases, which needs \"refresh\" (i.e. reindexing everything), from time to time, not very clear why exactly every time. That's the really important!

About cross-compilation: Are you count just adding one option '-m32' as a big and heavy new feature?! Seriously?! You don't have to change even the compiler! If you want to introduce new feature, try provide real cross-compilation for ARM architecture, for example. Something many customers would appreciate! If you want to know something more about cross-compilation, especially in Linux, take a look. The last, but not least, what kind of such compilation we are talking about, while the main application part is in Python (i.e. scripting language, which compile to platform indipendent bytecode) - only for few libraries?!

Good news is your \"new feature\" don't affect how menu appear of the 32-bit version (i.e. works, still). Unfortunately, the same statement isn't true for 64-bit build, still! For example, in 32-bit build every submenu looks like:

Same thing on 64-bit build looks like:

As could be seen, no any trace to any submenu (either changes or snooze).

Something else: while hover Dropbox systray icon the popups are different. For 32-bit build everything looks fine:

There is information what's going on. For 64-bit build such info is missing:

There is something wrong in your 64-bit build, as could be seen above.

There is also something wrong for both, 32 and 64 bit builds. File browser views stay inupdated after sync finished:

Please, Fix everything noted above!

Hi ,

I fully agree with ! \"Customers don't care how you compile your code or app. Customers pay you for features or services which you provide.\" Customers interest in working solutions and quality products! Yes, more QA is need, for everything. No for misbehaving (buggy) databases, which needs \"refresh\" (i.e. reindexing everything), from time to time, not very clear why exactly every time. That's the really important!

About cross-compilation: Are you count just adding one option '-m32' as a big and heavy new feature?! Seriously?! You don't have to change even the compiler! If you want to introduce new feature, try provide real cross-compilation for ARM architecture, for example. Something many customers would appreciate! If you want to know something more about cross-compilation, especially in Linux, take a look. The last, but not least, what kind of such compilation we are talking about, while the main application part is in Python (i.e. scripting language, which compile to platform indipendent bytecode) - only for few libraries?!

Good news is your \"new feature\" don't affect how menu appear of the 32-bit version (i.e. works, still). Unfortunately, the same statement isn't true for 64-bit build, still! For example, in 32-bit build every submenu looks like:

Same thing on 64-bit build looks like:

As could be seen, no any trace to any submenu (either changes or snooze).

Something else: while hover Dropbox systray icon the popups are different. For 32-bit build everything looks fine:

There is information what's going on. For 64-bit build such info is missing:

There is something wrong in your 64-bit build, as could be seen above.

There is also something wrong for both, 32 and 64 bit builds. File browser views stay inupdated after sync finished:

Please, Fix everything noted above!

Hi, Since Thursday, I have been having issues with the Preview App on macOS Catalina:

Everytime I open a PDF or document, the Preview App beach ball with the document being blurry for 2 seconds, then it opens fine.

After several tests (reset NRAM, caches, Onyx cleaning, Safe Mode, font cleaning, etc) I found the following:

Drag the file out of my Dropbox folder, and no issue whatsoever!

Drag it back in the dropbox folder, and here we go again, beach ball freeze when the preview App opens.

So there is definitely something up with Dropbox.

I also get this message in the console upon opening a file in Preview and beach balling:

Jan 24 15:36:26 MBP-16-JU com.apple.xpc.launchd[1] (com.getdropbox.dropbox.garcon.4xxxxxxxxx[1609]): Caller wanted oneshot behavior for pre-existing instance: caller = Preview

Problems started exxactly when last build of dropbox has been installed.

Regards,

Hi, Since Thursday, I have been having issues with the Preview App on macOS Catalina:

Everytime I open a PDF or document, the Preview App beach ball with the document being blurry for 2 seconds, then it opens fine.

After several tests (reset NRAM, caches, Onyx cleaning, Safe Mode, font cleaning, etc) I found the following:

Drag the file out of my Dropbox folder, and no issue whatsoever!

Drag it back in the dropbox folder, and here we go again, beach ball freeze when the preview App opens.

So there is definitely something up with Dropbox.

I also get this message in the console upon opening a file in Preview and beach balling:

Jan 24 15:36:26 MBP-16-JU com.apple.xpc.launchd[1] (com.getdropbox.dropbox.garcon.4xxxxxxxxx[1609]): Caller wanted oneshot behavior for pre-existing instance: caller = Preview

Problems started exxactly when last build of dropbox has been installed.

Regards,