Quick update: you should expect beta build from one of our guys soon.

Sorry, this info is not enough. Send us the diagnostic logs via tools > diagnostic menu and we'll see what's going on.

It's better to send the diagnostic logs to us via the feedback menu and we'll continue conversation in the ticket.

Unfortunately Compare and Sync folders in CloudBerry Explorer are legacy functions and provided "as is", with no support. We recommend our CloudBerry Backup software for backup purposes (transferring files to cloud).

Currently this version is undergoing QA testing, so the build will only be made public when they allow that, sorry.

The main problem here is Glacier storage class Itself.

Here's how this usually can be done with any other cloud destination:
You need to make sure the path in the cloud mirrors the one on the source by deleting/renaming the folders in the cloud and then synchronize the repository for that destination via tolls > options > repository menu in the backup software.

Since we're talking about Glacier, COPY operations are allowed due to how Glacier API operates, so the most efficient option is to start from scratch using new source location.

There's no particular release date yet, but it'll be rolled out pretty soon.

I've got good news for you, gentlemen: it'll soon be implemented in version 1.7.2(as of now, at least).

Here's a sneak peek

That appears to be a simple permissions issue. Make sure to assign "AmazonGlacierFullAccess" policy to that user in AWS console.

There's been an update for our Linux software with the fix for your issue. Feel free to install the new build and let us know if the problem reoccurs.

I understand the concerns, but Mac software is being constantly improved with each update and restoration should work fine as long as you provide correct encryption password during the procedure.

Yes, the encryption is proprietary, so you can only recover the data using our backup software.

Make sure you white-list 50.19.243.6 and cloudberrylab.com along with ports 80 and 443, that should be enough.

That is more of a Windows problem/limitation. If you map any drive using native Windows functionality it will behave in exactly the same way as within the Drive software.
I've also consulted with our Drive PM, and If your software is not able recognize mapped drives and converts the path to UNC automatically we can't really help with anything in that regard.

The root folder can be set up when creating/editing your mapped drives. As for the issue with naming, that appears to be specific to the 3rd-party software you're using to synchronize your files. From what I see you're specifying UNC path instead of the disk letter.

I guess I would need some clarification regarding your use-case and setup. If you're referring to the computer name, that part is just for the display name purposes, it's not a "functional" part of the path.

Here's an example:

Here you can see how it looks when simply opening the drive letter with your mapped drive

And here's how it looks when you copy that same path as text:

So in your case the path to the files will always be the same as long as the drive letter stays the same.

We use ports 80 and 443, as for the IP addresses you need to make sure your storage provider IPs are reachable from the machine.

We didn't receive any diagnostic logs from Ian, so make sure you're on the latest version of the software(2.5) and send us the logs if the problem reoccurs.

You can simply exclude that file when creating your backup plan and the software won't upload it from a different source location.

The software will upload the file one more time, since it has a different folder path in that case.