What’s the point of making a website / blog / LLC / career and building up a modicum of a following if you’re not going to use it as a forum for shitposting once in a while? Right? Right.
I wouldn’t post something as stupid as this if it was possible to actually post something about bugs with Amazon’s shitty photos app on their forum, but even that’s impossible at this moment because of some other shitty internal error on their amazon photos forums page, so, let’s start, yeah?
First, the obvious: Amazon Drive / Photos is an infuriating backup service for mac users (and possibly for all users), because the desktop app is shit.
The company provides a desktop app that, to its credit, can generally handle uploading a huge amount of files *fairly* reliably, but it chokes, a lot. Namely, if an error happens while a certain file is transferring, which if you’re uploading thousands of files, happens, it appears the app will stall the given upload thread and never recover. Translation: if you tell the app to upload up to 8 files at a time, and you upload a bunch of files overnight, one by one, those 8 threads will get hung up at some point when something goes wrong, and the app will sit forever without reaping the dead threads and starting more uploads – until you exit and reopen the app.
There’s the other usual laziness too – the app is only updated about once a year at best; changing settings like the number of simultaneous threads allowed or max bandwidth doesn’t do anything until the app is closed and reopened; clicking the “pause” button will show messages like “all uploads are resumed”; disconnecting from wifi in the middle of an upload of any size will mark every single file as canceled and you need to start all over again; and if you do one-time uploads (as I prefer to do rather than have the app constantly scanning backup folders), sometimes the app will miss files, so you need to make sure to upload twice, and so on.
But, the app gets a lot right. Under the covers, it compares md5s of your local file and what’s already been uploaded, so it saves time and bandwidth not re-uploading files that are already there. It’ll upload *huge* (20GB+) files without any problem at all, and it’ll handle thousands of files too – as long, as mentioned above, the threads don’t hang and you don’t disconnect from wifi, etc. All in all, if you can handle closing and reopening the app once in a while uploading the half-terabyte of photos you shot over the past year, it works.
So why not move to another provider like Backblaze that supports rclone? Because I’m lazy, and when I poked around recently, these other providers demand to have an app scanning your hard drive to back stuff up – which isn’t what I need, I need to upload organized archives of files once in a while – which it would seem like a tool like rclone could do, were it not for places like Backblaze requiring the user to pick random uuids that somehow don’t clash with other users uuids for buckets that files go in, and don’t forget that the buckets are a max of 5GB, and if you have a file larger than that, don’t forget to manage X buckets and to splice the file back together when you download it back, and even without that problem, don’t forget to organize all of your files into 5GB chunks like we did 20 years ago burning DVD-R backups, what the fuck, Backblaze and every other S3-based bullshit cloud service? Let me upload my files, store them on ice for me reliably, and that’s it, that’s all I need.
For better or worse, Amazon Drive / Photos does that for me, albeit with a ton of pain.
Anyway, that’s the end of the rant. If you have a small amount of data and just want a nice online backup, look into Backblaze, google drive, dropbox, or others – Amazon’s Drive and Photos app are neglected and not worth the hassle. If you’re uploading large swaths of data every few months for off-site backup and don’t want to get into super technical S3 bucket math, Amazon’s photo app is seemingly the only option.
Unless, of course, you name a file this:
114 – Montage Of Heck (Long) [4-Track Tape Collage].mp3
That specific filename will not upload to Amazon Photos with the mac desktop app, but this one will:
101 – Montage Of Heck (Short) [4-Track Tape Collage].mp3
From some theorizing and googling, to me, it looks like the mac app isn’t URL encoding brackets when it attempts to tell amazon’s servers about the file, and tomcat on the server side of things is bitching about the brackets not being escaped. I know this, because this file uploads fine (with brackets replaced with parens):
114 – Montage Of Heck (Long) (4-Track Tape Collage).mp3
Seems like a simple enough fix, someone on the mac app side needs to double check that bracket characters are escaped in their URLs per RFC 3986 – and maybe that’ll happen when the app is updated again in 2024.
On the off chance that one of the Amazon photos app developers ventures out of the Amazon echo chamber that currently prevents any sort of user feedback on their forums and reads this post, here’s relevant log data from the app:
Process: com.amazon.clouddrive.mac Version: 7.18.0.1cad8567 OsBuildNumber: Mac 12.2.1 CrashTimeUtc: 1646432324428 CrashType: Managed_Transfer CrashDescriptor: 6c3a72fa8f89f91bf6fd655a29d738d5 ContentType: Unknown Http Response Exception CrashDuplicateCount: 1 MarketplaceID: ATVPDKIKX0DER CountryOfResidence: US Request: POST https://content-na.drive.amazonaws.com/v2/upload/multipart-upload?name=114+-+Montage+Of+Heck+(Long)+[4-Track+Tape+Collage].mp3&fileSize=53038304&conflictResolution=NONE&suppress=DEDUPLICATION&kind=FILE&parentNodeId=icX0crQRQO-NupvTRc0iOw Amazon.CloudDrive.Services.AmazonHttpResponseException: Unknown error occured HTTP Status 400 – Bad Request - Invalid character found in the request target [/v2/upload/multipart-upload?name=114+-+Montage+Of+Heck+(Long)+[4-Track+Tape+Collage].mp3&fileSize=53038304&conflictResolution=NONE&suppress=DEDUPLICATION&kind=FILE&parentNodeId=icX0crQRQO-NupvTRc0iOw ]. The valid characters are defined in RFC 7230 and RFC 3986 The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). java.lang.IllegalArgumentException: Invalid character found in the request target [/v2/upload/multipart-upload?name=114+-+Montage+Of+Heck+(Long)+[4-Track+Tape+Collage].mp3&fileSize=53038304&conflictResolution=NONE&suppress=DEDUPLICATION&kind=FILE&parentNodeId=icX0crQRQO-NupvTRc0iOw ]. The valid characters are defined in RFC 7230 and RFC 3986 org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:494) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:895) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1732) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:750)
—
Anyway, in summary, I wouldn’t post a useless screaming-at-the-void post such as this if it were possible to contact the amazon team and tell them something is wrong without getting roadblocked by twitter bots and the usual 21st century customer service gatekeeping circus of insanity, so here we are. Hopefully someday this issue will be seen and fixed, and perhaps the other glaring issues will be resolved as well.
