Delete old files script error, path too long.

This topic contains 7 replies, has 7 voices, and was last updated by  eden Mathew 1 year, 5 months ago.

  • Author
  • #14974

    Dickie Taylor

    I am getting this error running this script and wondering if there is something else that can be done with this to make it work with the long file names? I would appreciate any help!

    Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 26
    0 characters, and the directory name must be less than 248 characters.
    At C:\scripts\Deleteoldfiles3.ps1:3 char:14
    + get-childitem <<<< D:\Prod\localuser\ -recurse | where {$_.lastwritetime -lt (get-date).adddays(-14) -and -not $ iscontainer} |% {remove-item $_.fullname -force } + CategoryInfo : ReadError: (D:\Prod\localus... Schmidt Hammer:String) [Get-ChildItem], PathTooLongExcept ion + FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand

  • #14976

    Robert Westerlund

    Note! There might be ways to achieve this a lot easier than the one I suggest below, but this is at least one way to solve your problem.

    What you can do, is 'subst' a temporary drive folder to the root of your path using a Unicode path indicator prefix '\\?\' (given that all files beneath that path fall below the 260 character limit, otherwise you would have to do it for every path part which risk being longer than 260 characters, but I guess you get the idea). You can read more about the maximum path length limitation at

    Here's a sample of a script which uses 'subst' to get into longer paths, which worked on my Win8.1 machine:

    subst t: \\?\c:\this\is\the\root\of\my\too\long\path
    cd t:
    $deleteOlderThan = (Get-Date).AddDays(-14)
    Get-ChildItem -File -Recurse | Where { $_.LastWriteTime -lt $deleteOlderThan } | Remote-Item -Force

    This should get around the length problem.

    Again, this is given that you don't also have any path below the root which is longer than 260 characters, then you'd have to split it up and remove in batches. Perhaps a relatively simple solution would be to write a script which 'subst' into every path, looking for files. This means writing the recursion manually (but shouldn't be difficult at all), but it should work.

    Another solution to the problem would to not use the PowerShell cmdlets for retrieving and removing files and instead using PInvoke, calling into the Win32 APIs using Unicode paths all the time. You have code snippets for such PInvoke code in part two of the bcl team's three part blog series on long paths at

    That blog post series also mentions some things which are important to note regarding working with longer file names. I'll qoute a couple of paragraphs below:

    [...] about security, the \\?\ prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that \\?\ turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding '.' and '..', converting relative paths into full paths, and so on.

    Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \\?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

    – qoute from part 1 in the three part blog post series on

    And on why they are reluctant do just allow longer file names on a .NET front before everything in the underlying operating system (Win32 API) supports it:

    Other apps may not support this prefix, and may not be able to use these files

    Not all Win32 APIs allow this prefix, meaning that the file will not necessarily work with other .NET APIs

    – qoute from part 3 in the three part blog post series on

  • #15005

    Dickie Taylor

    Thank you for the help and I will read the above blog posts also and will let you know what I come up with or if I figure out something that works. God bless!

  • #15010

    Peter Kriegel

    Hi Dickie!

    I have written an TechNet Wiki Article to that Topic, with a few workarrounds:
    .NET, PowerShell Path too Long Exception and a .NET PowerShell Robocopy Clone

  • #19896

    Yomodo Moso


    Here's a solution that WILL help you:

    Import-Module [path-to-AlphaFS.dll]

    # Remove folder, subdirectories and files.
    [Alphaleonis.Win32.Filesystem.Directory]::Delete($path, $True)

  • #21429

    Dan Rich

    Actually i did faced same error. Then i did use Long Path Tool for removing path too long error. Hope it will works such as me.

  • #32207

    Damien Nemer

    I tried Long Path Tool and It really Worked For me!

  • #36169

    eden Mathew

    Long path tool is a great option to solve your problem. I use it and have no problem now.

You must be logged in to reply to this topic.