Akeeba Backup for WordPress

#30916 Bad support

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
PHP version
Akeeba Backup version

Latest post by on Friday, 15 March 2019 18:17 CDT

In this ticket #30007 I am tall about bug with %2F in the filename instead of using subdirectories.

You wrote that there is no bug.
Rudely made me an idiot.
And after that you just closed the ticket.

And now what am I seeing?
In version 3.4.0, you write that you fixed this bug.

Your support sucks.
Indeed, why solve the user's problems, if it is easier to write that there is no error.

When the license is over, I will consider whether it should be renewed or better to use another plugin.

Akeeba Staff
The ticket you are referring to is private and this one is public. I am making your old ticket public so people can see what transpired in ticket 30007.

First, let me apologize for any miscommunication between us. As you'll see if you read this reply through, the problem was that it's a bug in the Google Storage API which cannot be reproduced easily and we were not allowed access to an affected server. This led to a lot of guesswork which resulted in more miscommunication between us.

To be clear. This was NOT a bug in Akeeba Backup. This was a bug in Google Storage. What we did in late January 2019, five months after your ticket, is work around Google's bug. The bug is extremely tricky to reproduce and the information you gave us would not lead me to reproducing it. The only reasonable conclusion I could have arrived at that point in time is that you were confused. Reading the ticket again, seeing what information was available to me, I don't see any other way it could have been handled except maybe telling you around August 25th that since the issue cannot be reproduce on the test site you gave us access to we cannot help you any further so either close the ticket or give us access to the affected site. I should have done that, per our Terms of Service, but I thought it was rude so I tried to stupidly help you based on the partial information I had at hand. I apologise for that. Next time I will definitely stick to the Terms of Service. I wrote them to avoid the very rare miscommunications like this one.

Now let's analyse what happened in your ticket and after your ticket. This will let you understand why we could not have possibly helped you and why five months later we did manage to reproduce Google's bug and work around it.

Your ticket was open between July and September 2018. When you filed your ticket we checked that our implementation of Google Storage JSON API was according to the official documentation provided by Google. It was. We ran several tests using my own Google Storage account and could not reproduce the issue. This was done on my local development machine, a live server controlled by me and a live, test site controlled by you.

At this time, all attempts to reproduce your issue were negative, i.e. your issue could not be reproduced except by you, on your real site. However, you would not give us access to your real site. You gave us access to a test site. We could not reproduce the issue there. You accepted that the backup transfer of the test site is working perfectly on August 24th. So, at this point, I reasonably believed that there is no bug: we follow Google Storage API's documentation to the letter and it works perfectly on three different sites, including one you control and which you verified yourself is working. The only reasonable conclusion I could come to at that time, given this information, is that you are somehow getting confused. That's why I closed the ticket. There was no reasonable way I could have ever known that there was a bug in Google's API.

With the hindsight of knowing what Google's bug is, I now know why we were misled. Google's bug only affects multipart uploads which only occur on very large sites. The test site you gave us was tiny. As a result, it was a single part upload. Single part uploads are a different API call to multipart (chunked) uploads. The single part upload API call is NOT affected by Google's bug.

Fast forward January 2019. A user comes with the same issue. However, he gave me access to his real site, a big site. I see that the problem can be reproduced there. This is the part that was missing from your ticket; we never got access to a server where the issue can be reproduced. This is crucial. This is why we ask for access to your sites when we try to help with issues we can't reproduce on our development machines. We don't care to see how your sites are set up. We don't care about your content. We only care to have a reproducible issue. If the issue is not reproducible we can't help fix it.

Having an affected server and profile I transfer his known-bad backup profile from his server to my server. I can now reproduce the issue. Awesome. Now I can start tweaking things and taking everything apart to see what's going on. The only instance of %2F I see anywhere in the data flowing to and from Google Storage is when we URL-encode the filename in the beginning of a chunked upload per the official Google Storage API documentation. At this point I'm thinking "Google is a multi-billion company that makes $82 million of profit every single day, they can't have screwed this up, can they?". But I remove the URL encoding anyway because one thing I've learned in this business is trust no-one, especially big tech companies. Lo and behold, it now works.

That's how I worked around Google's bug and wrong documentation. Because someone gave me access to the site that was not working properly. You hadn't. There was, objectively, no reasonable way I could have reproduced Google's bug given the information and access to a working (per your admission) site that you provided in 2018.

Again, please accept my apologies for the miscommunication between us. At no point did I believe or even think that you are an idiot. I genuinely thought that you were somehow confused as to what was going on. Given the information I had at the time there's no other conclusion I would have arrived. If you step into my shoes you'll see that this is true.

I do accept that it should have been handled better. In fact, by August 24th you accepted that your test site is working. At this point I should have told you that since you accept there is no issue I am closing the ticket. If you still experience the issue give me access to an affected site or I can't help you per our Terms of Service. The reason I've put that provision in the Terms of Service is because this has happened before. I should stop trying to be nice to people and give exceptions to the rules. I should stick by the rules because at least people will think that I'm an asshole who's a stickler for rules, not an incompetent idiot. Fair enough?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!