Skip to content

On Windows, Remove-Item unexpectedly fails if the target directory path happens to end in a backslash #15248

Closed
#15260
Closed
On Windows, Remove-Item unexpectedly fails if the target directory path happens to end in a backslash#15248
#15260
Labels
Needs-TriageThe issue is new and needs to be triaged by a work group.OS-WindowsWG-Cmdletsgeneral cmdlet issuesWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

Description

@mklement0
Michael Klement (mklement0)
opened on Apr 16, 2021

Steps to reproduce

# Switch to a temporary directory.
Push-Location -ea Stop ($tmpDir = (New-Item -Type Directory -Force (Join-Path Temp:/ $PID)).FullName)

try {

  # Create two directories with one file each in them.
  $null = New-Item -Type Directory -force foo1, foo2
  $null = New-Item -force foo1\t.txt, foo2\t.txt

  # Remove the first one with WITHOUT a trailing "\"
  { Remove-Item .\foo1 -Recurse -ErrorAction Stop } | Should -Not -Throw

  # Remove the second one with WITH a trailing "\"
  # This is also what you'd get with tab-completion.
  { Remove-Item .\foo2\ -Recurse -ErrorAction Stop } | Should -Not -Throw

} finally {
  # Clean up.
  Pop-Location; Remove-Item $tmpDir -Recurse
}

Expected behavior

Both tests should succeed: whether the target directory is specified with a trailing path separator or not should not make a difference.

Actual behavior

On Windows, removal fails when the target path ends in \:

Cannot remove item C:\Users\jdoe\AppData\Local\Temp\8656\foo2\: The directory is not empty.

Note:

  • The problem only occurs if the target dir. is non-empty.
  • It seems to have been introduced in v7.2.0-preview.5

Environment data

PowerShell Core v7.2.0-preview.5 on Microsoft Windows 10 Pro (64-bit; Version 20H2, OS Build: 19042.928)

Activity

  1. Michael Klement (mklement0)
    added
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Apr 16, 2021
  2. Ilya (iSazonov)
    added
    Area-Cmdlets-Core
    WG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
    OS-Windows
    on Apr 16, 2021

  3. iSazonov commented on Apr 16, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 16, 2021
    Collaborator

    Remove-Item .\foo\

    I'd expect follow should works - Remove-Item .\foo\ -Recursive.

  4. mklement0 commented on Apr 16, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 16, 2021 · Hidden as outdated
    Author

  5. iSazonov commented on Apr 16, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 16, 2021
    Collaborator

    I manually create the tree in c:\tmp and Remove-Item works as expected without an error.

  6. Michael Klement (mklement0)
    changed the title [-]On Windows, Remove-Item -Recurse unexpectedly fails if the target directory path happens to end in a backslash[/-] [+]On Windows, Remove-Item unexpectedly fails if the target directory path happens to end in a backslash[/+] on Apr 16, 2021

  7. mklement0 commented on Apr 16, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 16, 2021 · Hidden as outdated
    Author

  8. iSazonov commented on Apr 16, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 16, 2021
    Collaborator

    No error too.

    PS C:\tmp> Push-Location -ea Stop ($tmpDir = (New-Item -Type Directory -Force (Join-Path Temp:/ $PID)).FullName)
PS C:\Users\1\AppData\Local\Temp\3424>  New-Item -Type Directory -force foo

    Directory: C:\Users\1\AppData\Local\Temp\3424

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          16.04.2021    22:30                foo

PS C:\Users\1\AppData\Local\Temp\3424> Remove-Item .\foo\ -Recurse -ErrorAction Stop
PS C:\Users\1\AppData\Local\Temp\3424> Pop-Location; Remove-Item $tmpDir -Recurse
PS C:\tmp>

  9. iSazonov commented on Apr 16, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 16, 2021
    Collaborator

    Maybe you already have a locked file in C:\Users\jdoe\AppData\Local\Temp\8656\foo\ ?

  10. mklement0 commented on Apr 16, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 16, 2021 · Hidden as outdated
    Author

  11. iSazonov commented on Apr 16, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 16, 2021
    Collaborator

    I wonder how our CI tests are passed.

  12. mklement0 commented on Apr 16, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 16, 2021
    ContributorAuthor

    So you're now seeing the problem too?

    I wonder how our CI tests are passed.

    Without having looked at them: Perhaps the particular combination at hand - non-empty target dir., trailing \, -Recurse -isn't being tested.

  13. mklement0 commented on Apr 16, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 16, 2021 · Hidden as outdated
    Author

  14. iSazonov commented on Apr 17, 2021

    @iSazonov
    Ilya (iSazonov)
    on Apr 17, 2021
    Collaborator

    It is a regression after #14902 (again symlinks 😄).

  15. mklement0 commented on Apr 17, 2021

    @mklement0
    Michael Klement (mklement0)
    on Apr 17, 2021
    ContributorAuthor

    Thanks for digging.
    I've hidden most of my previous comments.

  16. Rob Holt (rjmholt)
    closed this as completedin #15260on Apr 27, 2021
  19. Ryan Yates (kilasuit)
    added
    WG-Cmdletsgeneral cmdlet issues
    and removed
    WG-Cmdlets-Core
    on Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs-TriageThe issue is new and needs to be triaged by a work group.OS-WindowsWG-Cmdletsgeneral cmdlet issuesWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions