Does restore status reporting have a bug?

Support
1

The restore was counting up to 198 (files?) and 3.6 GB. It seemed odd that it exceeded 198 and reached 199 and continued to run for quite a while with 100% completion and 0s remaining.

Upon completion it stated 166 files were restored. I am assuming that is perhaps because there were 32 (or 33?) existing files in the target directory?

…removed previous lines for brevity…
Processed 197 (3.5 GB) of 198 (3.6 GB) 15.6 MB/s (99.2%) remaining 1s.
Processed 198 (3.6 GB) of 198 (3.6 GB) 14.3 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 12.5 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 11.8 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 9.4 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 9.1 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 7.7 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 7.3 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 6.7 MB/s (100.0%) remaining 0s.
Processed 199 (3.6 GB) of 198 (3.6 GB) 6.7 MB/s (100.0%) remaining 0s.
Restored 166 files, 33 directories and 0 symbolic links (3.6 GB).

2

There is a flag to overwrite existing files on restore…

3

Are you suggesting the count of 199 exceeds the actual restored of 166 because 33 were not restored?

Looking at this again 166 files + 33 directories = 199 restored.

It still doesn’t explain how it would be at 100% with 0s remaining for quite awhile.

4

Side note: I don’t know what is your host file system but if it’s a *nix be aware that directories are considered files.