Yes, it's B2. I went back and made sure the file was deleted on the share and on the cloud through both Cloudberry's and B2's interfaces. And the stupid thing reappeared! Another round of deleting and the backup runs cleanly. I have now zipped the file and a couple of its ner-do-well friends and hopefully will see no more silliness. Thanks!

I have the replacement replacement drive in hand now (The second one. First time ever I've gotten a bad drive out of the box.) I'll let you know how it comes out.

>Grammar vs Engineers. It's a global problem. Shoooot. I worked for newspapers for years. Professional writers are as grammar challenged as the rest of us.

It threw a "Warning: One or more backup paths don't exist"* error on what looks to be the first run after the problem. It subsequently has run two more times, each showing "Success", with either 0 files backed up or, oddly, 1.

When I go into Backup Storage, all of the paths exist and files appear to be where they are supposed to be. So, crossing fingers, it appears to me that I can do "Synchronize Repository" and all will be good.

* Might need to convene the High Grammar Court on that error message :-)

Cool. So, in my case, should I just use the same backup plan that I already have built and do a "synchronize repository"? (After I have the files back at the same path, of course.) Or do I need to make a new backup plan?

And is it going to be an issue that the backup ran and saw the empty and/or corrupt directories?

Thanks!

Sounds good.

Progress feedback is really important, especially where cloud storage is involved. I don't suppose it needs to be terribly precise. I've seen a bunch of backup programs with more or less the same problem: people try to parse out precise information about how far along the backup is from whatever is there, no matter how imprecise it might be. Human nature, I guess. They need to know what they need to know. Thing is, I haven't seen anybody do a great job of making clear the precision or lack of it in the available information. So, viewed in that light, you've got a clear playing field.

Indeed. As the backup neared completion, the total file size incremented up to a value slightly higher than what the OS reported and the progress bar jumped up to match what was being reported at the right-hand end of the bar. But the value for size in the Info section remained out of whack until the very last. I don't think any harm was done.

This seems cosmetic to me. But it is a UX thing. Maybe a little better labeling would help. And progress feedback becomes kind of important in a SOHO environment when you are dealing with biggish backups and smallish upbound bandwidth.

Maybe CBB should invest in some UI tweaks in the next version cycle. Don't get me wrong, this isn't (to me) something that would drive a decision on whether or not to use the product. It just looks a little discombobulated.