The main community feedback appears to want to opt into progress. However, the current design pattern for PowerShell is to control this via $ProgressPreference. Perhaps the Cmdlets WG should discuss this.

This to me looks better & if we could in future on per cmdlets change progress preferences like Error action etc this would be a nicer opt out mechanism which I'll raise another issue to discuss this idea shortly

My comment #18728 (comment) is still actual.
I believe it makes no sense to pre-calculate the total size and number of files. (How about implementing Measure-Items?) These values could have been useful in the complete message, but we remove it immediately. Also the design is not address "freezing" on large files. This can be achieved by simple asynchronous copying, as well as the initial delay in the display, which is already implemented in some MSFT modules.

I've moved the calculation of the totals to a new thread which removes the concern about impacting the start of copying.

The @PowerShell/wg-powershell-cmdlets discussed this and agrees on the current design which is to asynchronously collect the total files/bytes information at the start of copying. However, estimating time remaining has never proven to be accurate and may raise more concerns so we recommend not including the time remaning.

I'm good with it, and I think progress should be default, its convention to expect some commands to emit progress and some not, I can't imagine there's a lot of breaking changes where someone would be explicitly capturing the progress stream and sudden introduction of copy-item results into that stream would break their flow, it would have to be very very niche. I should note I am one of those theoretically "niche" people as the Pester VSCode extension breaks output into streams, but I just silently discard progress as its not useful so this wouldn't break me for instance.

This change could benefit from the utils function DisplayHumanReadableFileSize that I wrote for my Invoke-Webrequest progress bar to calculate file size unit (KB, MB, GB, etc) so that it's not hard coded to MB, see my PR #14611

The @PowerShell/wg-powershell-cmdlets discussed this and agrees on the current design which is to asynchronously collect the total files/bytes information at the start of copying. However, estimating time remaining has never proven to be accurate and may raise more concerns so we recommend not including the time remaning.

@SteveL-MSFT - Re the last point I'd say that in line with other tooling this gives only an estimation and is how we'd expect it based on all the potential reasons why it may not finish as quick as we'd like, which inc CPU, network, disk, or memory contentions that are out of most users control. This at least on windows can be overriding by what priority we give the process running this task, which comes with its own set of risks but is one that allows additional flexibility going forward. Was that aspect considered? Because if not it may be good to review again.

@bergmeister it already should benefit from it I think thou @SteveL-MSFT or others may correct me if I am wrong here

The @PowerShell/wg-powershell-cmdlets discussed this and agrees on the current design which is to asynchronously collect the total files/bytes information at the start of copying. However, estimating time remaining has never proven to be accurate and may raise more concerns so we recommend not including the time remaning.

@SteveL-MSFT - Re the last point I'd say that in line with other tooling this gives only an estimation and is how we'd expect it based on all the potential reasons why it may not finish as quick as we'd like, which inc CPU, network, disk, or memory contentions that are out of most users control. This at least on windows can be overriding by what priority we give the process running this task, which comes with its own set of risks but is one that allows additional flexibility going forward. Was that aspect considered? Because if not it may be good to review again.

File progress estimations are notoriously difficult to do, moreso on spinning rust than SSDs, because little files take exponentially more time per GB than big files due to the overhead of transfer setup/teardown. Estimates can be based on how many files left, how much throughput, or as advanced as "bucketing" certain file sizes into groups and taking a weighted average of the gb/sec transfer time of those files. Any way you slice it the estimate can be thrown off very easily, so while I personally don't see any harm to it, someone who doesn't understand why the estimates vary so wildly or are inaccurate may not be so forgiving.

Took care of most of the feedback.

@kilasuit I believe the latest update addresses your concerns. See the updated gif.

@bergmeister Updated using your humanizer code.

@SteveL-MSFT I'd still like to see an estimated amount of time just like in file explorer copy or just like most other copying utilities out there. though perhaps this could be added via an additional parameter instead of being the default?

@SteveL-MSFT I'd still like to see an estimated amount of time just like in file explorer copy or just like most other copying utilities out there. though perhaps this could be added via an additional parameter instead of being the default?

Are you sure 🤔 😅

As funny as that is @bergmeister I am sure

Especially if you look at things like estimated download times in any other software (which is essentially the same thing, just a different way of thinking of it)

The reason being is that you can by seeing that more easily work out, when you might be able to come back to that series of tasks and start the next one, which for many in interactive scenarios is what they need to be able to manage all of their many spinning plates.

@iSazonov feedback noted. For the latter, we do have existing $ProgressPreference that should be used in automation and we also have the new -ProgressAction as well.

We need something magic for interactive scenarios in which all interactive features must be deactivated. We have NonInteractive command line parameter - can we use it for this purpose? For example, if the script is run by Task Scheduler.

I agree that we should look to expand how non-interactive works & this should be discussed in an new issue @iSazonov do you want to raise it?

This PR has 59 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Small
Size       : +57 -2
Percentile : 23.6%

Total files changed: 4

Change summary by file extension:
.cs : +51 -2
.resx : +6 -0

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@iSazonov I would suggest we take this PR so we can get user feedback. The risk of adding additional fields (as there's already existing ones in FileSystemProvider) is minimal. You have valid concerns about non-interactive scenarios and should be discussed in a new issue. Note that if you use pwsh -noninteractive then prompt is disabled. However, progress specifically doesn't block noninteractive use and some users may want to see progress. Progress can already be suppressed via $ProgressPreference.

@iSazonov perhaps you should open a new issue where -noninteractive results in different defaults for the preference variables? It would be a breaking change, however.

@iSazonov feedback noted. For the latter, we do have existing $ProgressPreference that should be used in automation and we also have the new -ProgressAction as well.

We need something magic for interactive scenarios in which all interactive features must be deactivated. We have NonInteractive command line parameter - can we use it for this purpose? For example, if the script is run by Task Scheduler.

I agree that we should look to expand how non-interactive works & this should be discussed in an new issue @iSazonov do you want to raise it?

Since ProgressBar is considered unimportant and unimportant, based on previous experience I have no desire to fall into lifeless discussions and especially unanswered PRs.

🎉v7.4.0-preview.2 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes