Skip to content

copy progress in 7.4 preview 3 does not work if files are in a single directory and does not show correct total to copy #19600

Closed

Description

Prerequisites

Steps to reproduce

I have a digital camera memory card with a root folder DCIM and 3 sub folders - the first contains ~ 250 files, the second 500 files and the third ~250 files. Average size is 44MB Roughly 44 GB to copy.

Copy speed from my card reader is ~100MB/sec, so copying the recent files from one folder will take 1-2 minutes, and the new progress bar would be nice.

copy D:\DCIM\140PENTX\* C:\temp\deleteme\ -Recurse
Displays no progress

copy D:\DCIM\* C:\temp\deleteme\ -Recurse
Displays progress as in the video at #18735 HOWEVER it only shows the count of files and number of bytes to copy for the first directory. ie. instead of 1000 files /44 GB it shows 251 files,

Expected behavior

All large copies show progress

Actual behavior

Copying a lot of data from one directory does not.

Error details

No error. Command runs, but shows no progress.

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.0-preview.3
PSEdition                      Core
GitCommitId                    7.4.0-preview.3
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

Untitled.video.mp4

Activity

  1. SteveL-MSFT commented on Oct 2, 2023

    @SteveL-MSFT
    Member

    The problem is that when copying a single folder, it's just a single .NET API call, so there's no way to know and write progress. We would have to split it into individual copy calls to be able to render progress which would slow down the operation. I think the best we could do is show a "progress" pane with the total number of files to be copied, but it wouldn't show progress, just that copying was happening.

    If the WG decides not to add a static progress pane, then we should at least document this behavior so it's not surprising.

  2. added
    PowerShell-Docs neededThe PR was reviewed and a PowerShell Docs update is needed
    and removed
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    WG-NeedsReviewNeeds a review by the labeled Working Group
    on Oct 18, 2023
  3. theJasonHelmick commented on Oct 18, 2023

    @theJasonHelmick
    Collaborator

    Thank you James O'Neill (@jhoneill) -- The Interactive WG reviewed this issue. The implementation of this feature is not fully understood and needs further investigation. We are planning to address this during the 7.5 development timeframe.

  4. SteveL-MSFT commented on Oct 18, 2023

    @SteveL-MSFT
    Member

    @PowerShell/powershell-committee discussed this. We can investigate showing a static progress message when copying lots of files that don't result in subfolders being copied.

  5. added
    Committee-ReviewedPS-Committee has reviewed this and made a decision
    and removed
    Review - CommitteeThe PR/Issue needs a review from the PowerShell Committee
    on Oct 18, 2023
  6. jhoneill commented on Oct 19, 2023

    @jhoneill
    Author

    The problem is that when copying a single folder, it's just a single .NET API call, so there's no way to know and write progress. We would have to split it into individual copy calls to be able to render progress which would slow down the operation. I think the best we could do is show a "progress" pane with the total number of files to be copied, but it wouldn't show progress, just that copying was happening.

    If the WG decides not to add a static progress pane, then we should at least document this behavior so it's not surprising.
    Yeah, I suspect for my case - copying dozens or a few hundred large files, the overhead of making one call per file is not significant. For the reverse case - copying thousands of small files the overhead of the extra copy calls and updating the progress after each one probably is. It's not at all clear what's best overall but it's unlikely that one choice will delight everyone. (I'm not wholly against saying 'if you want copy with progress, use the GUI or Robocopy, but it's not really expected in a shell')

    The issue I reported above was it actually reports wrong information, the numbers given being the first directory of multiple ones.

  7. microsoft-github-policy-service commented on Oct 19, 2023

    @microsoft-github-policy-service
    Contributor

    📣 Hey James O'Neill (@jhoneill), how did we do? We would love to hear your feedback with the link below! 🗣️

    🔗 https://forms.office.com/r/P926k48jRJ

  8. SteveL-MSFT commented on Oct 19, 2023

    @SteveL-MSFT
    Member

    James O'Neill (@jhoneill) just had a fix merged in, can you check if this is still a problem after we have a release with that change (or if you're adventurous build that branch)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Committee-ReviewedPS-Committee has reviewed this and made a decisionIn-PRIndicates that a PR is out for the issuePowerShell-Docs neededThe PR was reviewed and a PowerShell Docs update is neededWG-Interactive-Consolethe console experience

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions