Not sure what bugs you're referring to, but if you encounter any the best way would be to contact support.

As for the uploaded files, if they're in the cloud then they're in the cloud, I don't see any problems in both sets of logs you sent us, but let's continue communication in the ticket system.

SOME OF THE FILES are in the cloud. Is the backup complete?

I can tell you a problem with the logs. One problem is that the logs are not telling us why the UI hung. Another problem is that the user has no idea about the completion progress of the backup.

Are you guys seeing the UI hang? It would seem to me that you would have to know, and if you know, how can you let that kind of software reach the end user? That too does not build my confidence that the backup has integrity.

I see all of the back plan runs are successful(at least 10 latest ones). This is the first time I'm hearing about UI hanging. In any case, it's better to continue investigation in the ticket system.

So you are bailing out? If so, I don't blame you. In fact you are not contributing much to this dialog other than denial. If you are not aware of hang conditions, I would suggest that your experience with this software is minimal, either with the lack of SERIOUS TESTING or with inexperience with the product.

BTW, I tried your "ticket system" before trying this approach. Support is nonexistent in the "ticket system."

I like people that TAKE OWNERSHIP of users' problems. Does that kind of person exist at Cloudberry?

Please keep things civil here. As I already mentioned, I'm waiting for your feedback in the ticket system. Continuing technically-related conversation on forum will not be efficient in any way for both sides.

I am being civil.. I own a business. My best customers are the customers that make me aware of problems. Some customers become frustrated or uncomfortable with the honest discussion of problems. When or if the customer walks away, the problem does not get fixed.

I consider my behavior as necessary feedback to the team that helps to develop this product. Sometimes that feedback is tough to take, but again, I like people that take ownership of users' problems.

In the spirit of confining my discussion to one thread, I would like to understand this issue. I guess the deletion of a corrupt repository is not possible. I am using CloudBerry Explorer in an attempt to remove a repository that was created in a failed backup. The file count of one directory is now up to 960,000 files. I am guessing that this removal through the delete process could take days, or weeks,maybe months.

Deleting files is simply not a practical process for removing a corrupt repository.

I don't see any signs of "corruption" of your data in the cloud, it's impossible to corrupt anything once it's in the cloud, unless there are problems on storage side.

Removing hundreds of thousands of files might take some time to complete for obvious reasons, since this will require both sending a deletion request to the cloud and updating our database regarding any removals happening.

How do you verify the integrity of the backup? Of course, you don't have access to my source files. How do you know that the backup to my system is a backup with integrity?

I fail to see what is obvious about the fact that I should not be able to delete these files. The task apparently is beyond the capabilities of CloudBerry Explorer, but the removal of this directory should be possible through some means.

Maybe I have to reformat the drive and destroy all of the other repositories.