Can I see which files are causing sync errors via my Dropbox desktop app?

---

582374893 wrote:

...  I was browsing through my files and saw a file with a red cross on it, and after inspection it seemed it wasn't syncing because of an emoji in the filename.

...

---

The problem comes from fact every one symbol is represented/ mapped to particular code. Dropbox as a system don't support all possible codes, but restrict support only for symbols with corresponding codes up to 65535 (i.e. codes which can fit in 2 bytes only). Every one symbol above this "border" (including emoji - codes there are 128512 up to 128591) included inside file/folder name/extension, make the file unacceptable/unrecogniziable for Dropbox (i.e. cant be uploaded correctly). I already signaled for this. Let's hope we will survive till the moment gets fixed. :scream::sleeping:

---

582374893 wrote:

Okay, so you're saying there there is NO solution for this on Windows/Linux?

...

---

Good question! Very good question... Let's see if some Dropbox developer will take care for this discrepancy (and many others, also). The only thing Fiona can do here is forwarding the "signal", nothing more. :disappointed_relieved: I'm sure if there was any chance, she would fix the issue, but that's a developers work. :wink:

---

582374893 wrote:
..., I think that's extremely important to know, especially when I use the API and have scripts that are downloading into specific locations etc.

---

About downloading (either using Dropbox application on other  machine or through script), you couldn't expect any errors. Ones a file gets uploaded correctly, it's very unlikely some error to happens (successful upload, mean all symbols are acceptable both for Dropbox and for your machines). As I already noted above upload is troublesome in such a cases ( like yours, and not only! ). You don't have to worry about script usage. :wink:

Hope this adds some clarity both to you and to responsible developers.

Hey Здравко and 582374893, 

Our devs are always working for Dropbox to offer a unified experience. I am sorry this is not the case with this option for you, at the time.

I am sure I can help you solve this syncing issue and I will create a ticket to work on this, however please let me know if you checked for incompatible characters and also please get an advise from our API team for your specific set up. 

Thank you!

Fiona, Seems you haven't read my posts above careful enough (including links inside)! Ok I will repeat: Every one symbol which code is above 65535 (i.e. can't fit in 2 bytes) are unsupported from Dropbox system ( not just the application! ) for file/directory names. This was confirmed from development support (follow the links above). I want to add here: There is no such limitation in any of Dropbox supported platforms, natively! The "thin spot" here is Dropbox, nothing else! You can't use such symbols even through the web interface... Check it, to be sure. I already gave such a proposal in my previous post (on previous page), but seems you have ignored it. :thinking::wink:

PS: I'm not sure if you are familiar with the Dropbox API. If you are, can you explain why when a non-ASCII symbol is tagged, only available tag is "\u", but not "\U"? :thinking: There is significant difference between! :stuck_out_tongue_winking_eye:

I greatly appreciate your feedback and all the solutions you have provided in our Community Здравко. 

Just to answer the question. I am not an API specialist, unfortunately. This is why I am redirecting API requests to our API section, where he might find his answer or post about the details of his API set up so that our API team can get him an answer. :slight_smile:

Ooohh... Fiona,

:slight_smile::upside_down: My API related question is rethorical! I suspected you can't give direct answer, but I hoped your curiosity gets provoked. Anyway... the answer is more than clear. Let's see how the issue gets fixed (or we will left with the hope only). As I already mentioned, the problem is more deep, not just API or application (including web) related! The issue is related to the basic Dropbox system idea and corresponding limitations deeply embedded which have to be reconsidered. This will take long time, but will never end if not start. :wink:

My API question is related to supported symbol set. "\U" tag allow all possible Unicode symbols to be used (i.e. full Unicode support), "\u" - sets the limit, noted above! :nerd:

Almost same is valid for different support on the supported platforms (especially the differences in available features - not restrict only to discussed here). :cry:

Hope now the things get more clear.

PS: The main issue (missing symbols support), discussed here and in many other threads, could be solved if Dropbox reconsider file/directory names storing as ASCII-tagged. Features support is another story. Switching to "UTF8"-encoded internal storage for file/directory names will solve many issues going discussed in this forum! This is my solution proposal (if somebody from Dropbox system design take care).