I want to share an instructive story about Dropbox internal peculiarity.
I contacted their support about a Microsoft Word file that Dropbox fails to synchronize, and I attached the file to my support request.
The support’s answer was senseless as usual, but, somewhere deep in the answer, I encountered a link to my file stored in Dropbox’s Zendesk:
[link removed by moderator]
(The link is working fine at the time of this writing, but I am not responsible for it to work at any other moment.)
So what it’s all about: first, the Dropbox support people store files not in Dropbox itself, but in a third-party service (Zendesk). It seems a little suspicious to me: guys, you’re working for a company that claims to provide the best file hosting service in the world, but if you need to store a file for yourselves, then you resort to another company’s hosting service!
Second, this third-party service is working better than Dropbox: Zendesk has saved my file perfectly and provided a public link to it (it is the link above). But Dropbox itself cannot do either with this file. (You can see it for yourselves if you download the file and try to save it within your Dropbox.)
I find the situation both funny and shameful for Dropbox.
Update. Another funny thing is, that, on the Dropbox Forum, it turns out to be prohibited to discuss a link that was officially sent to a Dropbox user by Dropbox support team, according to some “community guidelines”.
Zendesk is the help desk system that Dropbox uses. You uploaded the file to Zendesk, so it's stored within the service. Dropbox didn't store the file there; you did by attaching it to your ticket.
Zendesk and Dropbox are completely separate services, providing different functions. There's no reason why files attached to your ticket would be (or should be) stored within Dropbox.
I've removed the link from your post, according to Community Guidelines.
I've removed the link from your post, according to Community Guidelines.
Then how would you tovarishch @Rich suggest to show a file to the readers of this thread if the file itself is the subject of the discussion?
A screenshot showing the issue would work just fine.
Also, the update you've made to your original post is incorrect. It is not prohibited to discuss a link. You can discuss the link all you want, but you can't post the actual link in the forums. The support system is not meant to be used to share files with anyone other than you and Dropbox support, and only as it pertains to your support request.
Hi @_-_, under Respect Privacy we outline that you should not share personal information.
The list of examples here is not exhaustive, but a link to your personal support ticket would fall under any other information that isn't publicly accessible.
As @Rich has said, you are absolutely free to discuss this link on the forum, but not post the actual link to your ticket.
You are also free to discuss support links sent to you by the Dropbox team, as long as that information is publicly accessible - for example a link to a Help Center article would be fine!
Well @Emma, but what would you suggest me to do in the following situation?
Suppose I would like to discuss an issue when Dropbox fails to synchronize a file. I want to show the file in question to other people for them to see for themselves that the file really doesn’t sync. Maybe somebody of these people will suggest an explanation, a fix, or a workaround for this issue. I think it seems oddly to discuss a problem with a non-synchronizing file without having the file.
So how exactly would you suggest me to make the file accessible to other people on the forum?
I agree that such a limitation is not a best thing, but private things (like link, generated from support system), which are not Your property entirely (the link, not the file), it's not acceptable to be shared (generally).
Anyway, despite the publication error, here is a problem related to restricted character set. Present day file systems support almost all printable symbols from Unicode to be part of (or entirely) file/directory name. That's the actual signal here! Limiting symbols to particular character set(s) and excluding another character set(s) is outdated long time ago. Dropbox service still use such restrictions:
On screenshots could be seen that not all valid (for the file system) characters are acceptable for Dropbox application. I have seen that many other service providers don't set such limits (checked using absolutely same elements -> in mobile application everything can be seen). So this thread could be count as proposal for future enhancements.
Something else: From the beginning of current thread (long time before Your post) I have tried post similar screenshots as those put here, but everything was marked as spam! Is this post a spam? I already asked @Jane (some time ago) what's going on and she promise me that this (and not only) will be checked. Can You help to @Jane about this?
Hope the matters are little bit clarified.
@Здравко posts can be flagged as spam for many reasons, for example, if the image is large, the post contains to many images, its a duplicate or it gets flagged for content. Our moderators regularly check spammed posts and restore them if necessary.
On your request for unicode in file names. You can find information on correcting filenames for syncing here and I'll pass your feedback and request along to the team.
In the link You posted above - on focus are problems related to unavailable support for particular symbols or special characters to be represented corectly, so particular files would be imposible to sync to particular platform. I understand this, but seems You didn't read carefully my post! The situation is just opposite and not covered in any way in the article. The symbols used, as could be seen, are supported and successfully used as a name to directory ( not in Dropbox account, but locally - in Dropbox directory! ), so the issue is not related in any way to the OS (or something like). The issue is that Dropbox application, as could be seen (cross in red circle), reject even to try sync. In the article isn't even a word about such a situation! There was some troubles with particular OS-es from past century (like Windows 95, 98, ME...) where extended character sets using (especially Unicode) was troublesome. Are such systems still in use? I don't think so. Such systems are not more supported either from Dropbox or from their supplier (primarily Microsoft). If I have to bet, Your app still keep some protections for such systems . Any OS in use present day (especially those Dropbox supported) have not any problems to use Unicode symbols in file/directory names. Introducing unrelated articles is not helpful. The good news is that the request is passed along. Let's hope Dropbox will make up for the lag.
About the spam politics: Ok, I fully agree that moderators have to check what's going on in different threads and acts as appropriate, when needed. In particular case: My first post in this thread was subset of my previous post, in fact. May be I have done something wrong (I don't think so but...). In the first reply @Rich explained why particular changes are made in the main post. Note: The main post is edited, not labeled as spam. My first post here (note again: subset of my previous post) was labeled as spam and seems permanently removed (even more: I was blacklisted for few days)! Could somebody explain me WHY? If I don't know why, I can repeat the same error again and I would have no idea again what's going on. Hope now it's more clear what exactly I'm asking for. @Emma, I address to You the question because a Community Manager have wider view what's going on and can ask the colleagues for the reasons (hope system logs can give more information ).
Have a great day!
If you need more help you can log a ticket with our Support Team here (expected response time 24 hours), or contact us on Twitter or Facebook.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!