Backup of zero byte files

Bug
#1

I think I may have discovered a very minor bug in backing up zero byte files, but not critical because the backup worked properly, meaning the zero byte files were bacled up properly.

  • This is using latest CLI.
  • My back end is OneDrive (It could also be a OneDirve problem, as it is not possible to uploade zero byte files via the OneDrive website)
  • Win10 Pro x64

Please describe what you are doing to trigger the bug:

  1. I ran my backup to make sure all files have been backed up.
  2. I then added 2 zero byte files files (no content) at different folder locations.
  3. I then ran my backup again

Please describe what you expect to happen (but doesn’t):
4. I expected to see in the backup summary New Files = 2, zero bytes uploaded.

Please describe what actually happens (the wrong behaviour):
5. The backup summary showed New Files = 0, zero bytes uploaded.

  1. I then listed my last backup and I could see the 2 new files in the list. I did not actually attempt to restore them, because I assumed if they are listed then they are backed up ok.

regards

How to read check stats
#3

Confirming that the bug is still present in version 2.2.1, under Windows 10 1903, backing up locally. The files get restored correctly but the output of the incremental backup is incorrect, as described (it doesn’t count empty files in the file count).

3 Likes
Duplicacy can't back up empty files?
#4

FWIW, I submitted a pull request that fixes this, back in April, so either it’s a low priority for @gchen or he doesn’t like my fix!

#5

@arikorn your PR contains multiple fixes. One of them is to fix a bug that I suspected doesn’t exist in the master branch. If you can trim down the PR to contain only the fix for this zero-byte file reporting bug that I’ll happily take it.

#6

@gchen, thank you for your reply. I can understand your hesitation in dealing with multiple issues, though to be fair it’s easy to confirm each issue. Two of the bugs make Duplicacy crash; one (the one discussed here) is purely cosmetic. Regardless, the PR code is yours, by the PR “rights agreement,” and I would like to encourage you to take as much or as little as you please.

To engage in a bit of philosophy, we could consider the case from each other’s point of view: from my POV it would be unethical and counterproductive to intentionally change a PR in a way that adds bugs back into your product, whereas from your POV, it would be a good use of your time to remove bugs from your product, and if you believe that part of the PR is buggy, then you would be right to remove it. The middle course would be if you could demonstrate that the PR is buggy, then our interests would align!

Regardless, I’m grateful for your decision to publish your code as open source, and to be quite honest, will not in any way be offended or inconvenienced if you choose not to incorporate the PR into future releases.

#7

As another (open source) dev, i can add one more reason why I want a multi-topic PR to be split in several smaller: it is much easier to track(link; refer to) each pr/feature separately when creating reports or statistics, asking for changes, or when creating the changelog, (by checking the merge commits, PRs, etc.), etc.