Suggestion: progress percentage

[Valentino]

I was copying large folder. It contained both large files and many small ones. And I noticed the following: progress shows 99% 1749 / 7404 files 1560.3 M / 1567.9 M (see screenshot (alt)).

I think progress bar would be more smooth if you showed average percentage value calculated by size and by number of files:

percentage by files size = 1560.3 / 1567.9 = 99.5%
percentage by files count = 1749 / 7404 = 23.6%
display percentage = (99.5 + 23.6) / 2 = 61.6%

What do you think about this?

[ghisler(Author)]

The percentage is currently strictly by size, not by number of files. I would have to know the overhead per file to handle also the file count. But that's unreliable because of fragmentation and how the files are distributed on the disk.

[MVV]

ghisler(Author), but you may set constant overhead per file (e.g. 128 or 256 bytes), it will smooth progress bars for folders with thousands of files anyway.

[Valentino]

I think the easiest way is what I proposed - just to take average of two percentages and no need to know overhead:

percentageForDisplaying = (percentageBySize + percentageByCount) / 2 = (doneFiles / filesToCopy + doneBytes / BytesToCopy) / 2 * 100

Smother progress bar for no cost.

[ghisler(Author)]

2MVV
Choosing the right value is EXACTLY the problem. Imagine copying a 10GB movie and many 10kByte text files. 128 or 256 bytes wouldn't do anything in this case.

2Valentino
Sorry but this would also be very misleading. Imagine copying a 10GB movie and one 10kByte file. With your calculation, TC would take a few minutes to go to 75% (50%+99.999999%)/2, and then jump to 100% in a fraction of a second. Not really better than going by size.

[Valentino]

2ghisler(Author)
Indeed, file count is less important than file size. Then how about weighs? For example, if file count is 10 times less important than file size, then:

percentageForDisplaying = (doneFiles / filesToCopy * 0.1 + doneBytes / BytesToCopy) / 1.1 * 100

[ghisler(Author)]

Well, the weight is obviously depending on the size of the files and the overhead per file, which is mainly determined by the disk seek speed. It's faster with SSDs than harddisks. The optimum would of course be to measure it somehow.

[MVV]

Christian, we need to compensate only average ammount of data that OS needs to read/write in order to find source file and create target (the rest will be proportional to file size). E.g. you may make it configurable...

Yes, maybe 256 bytes is too small, so we can try e.g. 4 KB or even more...

[ghisler(Author)]

The problem isn't the size of the data which is written, but the seek time of the harddisk. Therefore adding a fixed size value is the wrong approach.

[Valentino]

Yes, it's not possible to show absolutely exact progress but IMHO it makes sense to try to make it more smooth. I like MVV's idea about additional 4KB per file (most file systems are now NTFS with 4KB clusters).

[karlchen]

Hello, Christian.

Should this thread not be moved to the "Suggested Features" section. No bug reported, but a change is requested.

Kind regards,
Karl

[Hacker]

[mod]Moved to the Suggestions forum.

Hacker (Moderator)[/mod]