Windows Vista Forums

Embarrassing limitation in PowerShell

  1. #1


    UNIXLVR Guest

    Embarrassing limitation in PowerShell

    XCOPY has been a joke forever because, even though it was the best built-in
    tool for copying files, it was stupidly limited in the folder depth or path
    length that it would support (and then it would just quit when a path was
    too long instead of even trying to proceed). So then we got ROBOCOPY instead
    of Microsoft just fixing XCOPY.

    So now PowerShell comes out, the new "shell for administrators", but what
    error message do I get when trying to copy files:

    "Copy-Item : The specified path, file name, or both are too long. The fully
    qualified file name must be less than 260 characters, and the directory name
    must be less than 248 characters."

    Good lord...

    Aren't you embarrassed by this??? The new cutting-edge .NET-powered shell
    to trounce all Windows and UNIX shells...and you still can't support paths
    longer than 260 characters??? Ridiculous.

    Now, I'm not criticizing the copy-item cmdlet for not having every last
    ROBOCOPY bell and whistle, but don't you think copy-item should *at least*
    support "long" paths? This is pretty basic. I'm sure there's some
    under-the-hood explanation related to the .NET class being invoked for this
    bla bla bla...but who cares! It's a stupid embarrassing limitation whatever
    the explanation. I hope this post helps to make somebody fix it...



      My System SpecsSystem Spec

  2.   


  3. #2


    Don Jones [MVP] Guest

    Re: Embarrassing limitation in PowerShell

    Did you happen to log this as a bug on Connect? If not I'll be happy to do
    so.

    --
    Don Jones
    Windows PowerShell MVP
    Founder: www.ScriptingAnswers.com
    Co-Author: "Windows PowerShell: TFM"

    "UNIXLVR" <myaddr@mydom.com> wrote in message
    news:%23%233HIAEkHHA.4188@TK2MSFTNGP02.phx.gbl...
    > XCOPY has been a joke forever because, even though it was the best
    > built-in tool for copying files, it was stupidly limited in the folder
    > depth or path length that it would support (and then it would just quit
    > when a path was too long instead of even trying to proceed). So then we
    > got ROBOCOPY instead of Microsoft just fixing XCOPY.
    >
    > So now PowerShell comes out, the new "shell for administrators", but what
    > error message do I get when trying to copy files:
    >
    > "Copy-Item : The specified path, file name, or both are too long. The
    > fully qualified file name must be less than 260 characters, and the
    > directory name must be less than 248 characters."
    >
    > Good lord...
    >
    > Aren't you embarrassed by this??? The new cutting-edge .NET-powered shell
    > to trounce all Windows and UNIX shells...and you still can't support paths
    > longer than 260 characters??? Ridiculous.
    >
    > Now, I'm not criticizing the copy-item cmdlet for not having every last
    > ROBOCOPY bell and whistle, but don't you think copy-item should *at least*
    > support "long" paths? This is pretty basic. I'm sure there's some
    > under-the-hood explanation related to the .NET class being invoked for
    > this bla bla bla...but who cares! It's a stupid embarrassing limitation
    > whatever the explanation. I hope this post helps to make somebody fix
    > it...
    >
    >



      My System SpecsSystem Spec

  4. #3


    UNIXLVR Guest

    Re: Embarrassing limitation in PowerShell

    > Did you happen to log this as a bug on Connect? If not I'll be happy to do
    > so.


    I didn't, I don't know what "connect" is. Thank you very much for reporting
    it.



      My System SpecsSystem Spec

  5. #4


    Don Jones [MVP] Guest

    Re: Embarrassing limitation in PowerShell

    No prob. It's at http://connect.microsoft.com and it's open to the public,
    if you'd like to check it out. PowerShell is one of the programs you can
    "participate" in.

    --
    Don Jones
    Windows PowerShell MVP
    Founder: www.ScriptingAnswers.com
    Co-Author: "Windows PowerShell: TFM"

    "UNIXLVR" <myaddr@mydom.com> wrote in message
    news:eIcWwQPkHHA.4048@TK2MSFTNGP02.phx.gbl...
    >> Did you happen to log this as a bug on Connect? If not I'll be happy to
    >> do so.

    >
    > I didn't, I don't know what "connect" is. Thank you very much for
    > reporting it.
    >
    >



      My System SpecsSystem Spec

  6. #5


    Oisin Grehan Guest

    Re: Embarrassing limitation in PowerShell

    Hi unixlvr,

    Unfortunately this is nothing to do with powershell and cannot be
    fixed easily. You've run into the infamous MAX_PATH limitation. This
    is a system-imposed (e.g. windows) restriction, and has everything to
    do with backwards compatibility and legacy support, and nothing to do
    with bugs.

    Google for MAX_PATH and "f*cking hell" or somthing similar to find
    "contextually appopriate" discussions... ;-)

    - Oisin

    On May 6, 8:38 pm, "UNIXLVR" <mya...@mydom.com> wrote:
    > XCOPY has been a joke forever because, even though it was the best built-in
    > tool for copying files, it was stupidly limited in the folder depth or path
    > length that it would support (and then it would just quit when a path was
    > too long instead of even trying to proceed). So then we got ROBOCOPY instead
    > of Microsoft just fixing XCOPY.
    >
    > So now PowerShell comes out, the new "shell for administrators", but what
    > error message do I get when trying to copy files:
    >
    > "Copy-Item : The specified path, file name, or both are too long. The fully
    > qualified file name must be less than 260 characters, and the directory name
    > must be less than 248 characters."
    >
    > Good lord...
    >
    > Aren't you embarrassed by this??? The new cutting-edge .NET-powered shell
    > to trounce all Windows and UNIX shells...and you still can't support paths
    > longer than 260 characters??? Ridiculous.
    >
    > Now, I'm not criticizing the copy-item cmdlet for not having every last
    > ROBOCOPY bell and whistle, but don't you think copy-item should *at least*
    > support "long" paths? This is pretty basic. I'm sure there's some
    > under-the-hood explanation related to the .NET class being invoked for this
    > bla bla bla...but who cares! It's a stupid embarrassing limitation whatever
    > the explanation. I hope this post helps to make somebody fix it...




      My System SpecsSystem Spec

  7. #6


    UNIXLVR Guest

    Re: Embarrassing limitation in PowerShell

    > You've run into the infamous MAX_PATH limitation.


    Thank you for the lead Oisin, kind of amazing...

    If the MAX_PATH limitation is so well known, it should have been well known
    to the PowerShell developers too. ROBOCOPY and XXCOPY don't have this
    problem, so the PowerShell team can't throw up their hands and "blame it on
    Windows" since they can use the same tricks to get around it as these tools
    use.

    "Write cmdlets that do one thing and do it well."
    --Doug McIlroy










      My System SpecsSystem Spec

  8. #7


    Don Jones [MVP] Guest

    Re: Embarrassing limitation in PowerShell

    I tend to agree. I mean, yay Windows and yay backward compatibility, but the
    PowerShell team is definitely smart enough to get around whatever - they've
    had to work around plenty already! I don't blame them, and what we have in
    v1 rocks, but this is one of this things that hopefully can be looked at for
    vNext. If it's Windows' fault, well, go beat up on those guys or something
    <grin>.

    Anyway, I logged it in Connect. We'll see what happens, though I suspect
    it'll be closed with "By Design." If anyone wants to go in and "vote" for
    this issue in Connect (connect.microsoft.com), it'll help raise its profile
    for the team.

    --
    Don Jones
    Windows PowerShell MVP
    Founder: www.ScriptingAnswers.com
    Co-Author: "Windows PowerShell: TFM"

    "UNIXLVR" <myaddr@mydom.com> wrote in message
    news:O4YlgKckHHA.4772@TK2MSFTNGP05.phx.gbl...
    >> You've run into the infamous MAX_PATH limitation.

    >
    >
    > Thank you for the lead Oisin, kind of amazing...
    >
    > If the MAX_PATH limitation is so well known, it should have been well
    > known to the PowerShell developers too. ROBOCOPY and XXCOPY don't have
    > this problem, so the PowerShell team can't throw up their hands and "blame
    > it on Windows" since they can use the same tricks to get around it as
    > these tools use.
    >
    > "Write cmdlets that do one thing and do it well."
    > --Doug McIlroy
    >
    >
    >
    >
    >
    >
    >
    >
    >



      My System SpecsSystem Spec

  9. #8


    Oisin Grehan Guest

    Re: Embarrassing limitation in PowerShell

    On May 8, 6:45 pm, "UNIXLVR" <mya...@mydom.com> wrote:
    > > You've run into the infamous MAX_PATH limitation.

    >
    > Thank you for the lead Oisin, kind of amazing...
    >
    > If the MAX_PATH limitation is so well known, it should have been well known
    > to the PowerShell developers too. ROBOCOPY and XXCOPY don't have this
    > problem, so the PowerShell team can't throw up their hands and "blame it on
    > Windows" since they can use the same tricks to get around it as these tools
    > use.
    >
    > "Write cmdlets that do one thing and do it well."
    > --Doug McIlroy


    I think you're still a bit quick to comment here - stop and think for
    a minute about this one. Powershell doesn't really have some max_path
    (260) char limit for move-item/copy-item etc. This limitation stems
    from the FileSystemProvider, which is designed to interface with the
    Windows filesystem, which is where the real limitation lies. move/copy
    cmdlets do not have this limitation when working with other providers
    (e..g not the filesystem) for example. Robocopy and the like is
    designed to operate with multiple filesystems, not all of them windows
    based. It can copy to and from UNC paths, which may or may not be
    hosted on Windows. There is no such limitation within the CIFS specs
    for example, nor with unix filesystems. If you used robocopy to copy
    from a unix path (which was > max_path) to windows, robocopy would
    fail with the same problem (if you tried to recreate the source path
    on the destination and it was bigger than max_path).

    In reality, the actual max_path for NTFS is 32k (e.g. 32768 chars),
    but compatibilty with win16/win32 apis demand that we stick to 260
    chars (including drive letter, colon, backslash and terminating null,
    leaving us actually 256 chars). If you want to work with longer paths,
    there is a special syntax \\?\ for working directly with devices. At
    the end of the day, no amount of "cleverness" from the powershell team
    is going to fix this. Powershell sits on win32; win32 has the
    problem.

    THIS IS NOT A POWERSHELL ISSUE. THIS IS A KNOWN PLATFORM ISSUE FOR
    MANY MANY YEARS.

    welcome to windows boys.

    - Ois


      My System SpecsSystem Spec

  10. #9


    UNIXLVR Guest

    Re: Embarrassing limitation in PowerShell

    > no amount of "cleverness" from the powershell team
    > is going to fix this. Powershell sits on win32; win32 has the
    > problem.


    I presume ROBOCOPY and XXCOPY also go through Win32, but they don't have
    this problem. I try to use standard XCOPY to copy files from a long path on
    C: to M:, both of which are formatted NTFS, and it fails. I use ROBOCOPY or
    XXCOPY to do the same, it works. Whatever ROBOCOPY and XXCOPY are doing,
    can't the PowerShell cmdlets do that too when interacting with NTFS on
    Windows systems?


    > If you want to work with longer paths, there is a special
    > syntax \\?\ for working directly with devices.


    Very interesting! Do the PowerShell cmdlets support this syntax too? I've
    never seen it before and my Googling doesn't bring up much. An example
    would be great, thank you.



      My System SpecsSystem Spec

  11. #10


    lrbell Guest

    Re: Embarrassing limitation in PowerShell

    On May 9, 11:50 am, "UNIXLVR" <mya...@mydom.com> wrote:
    > > no amount of "cleverness" from the powershell team
    > > is going to fix this. Powershell sits on win32; win32 has the
    > > problem.

    >
    > I presume ROBOCOPY and XXCOPY also go through Win32, but they don't have
    > this problem. I try to use standard XCOPY to copy files from a long path on
    > C: to M:, both of which are formatted NTFS, and it fails. I use ROBOCOPY or
    > XXCOPY to do the same, it works. Whatever ROBOCOPY and XXCOPY are doing,
    > can't the PowerShell cmdlets do that too when interacting with NTFS on
    > Windows systems?
    >
    > > If you want to work with longer paths, there is a special
    > > syntax \\?\ for working directly with devices.

    >
    > Very interesting! Do the PowerShell cmdlets support this syntax too? I've
    > never seen it before and my Googling doesn't bring up much. An example
    > would be great, thank you.


    Don, you'll get my vote on whatever site that is... Just ran into
    this while traversing a huge file server and it makes for a tough sell
    when auditing file system content. I appears the less technical
    beings tend to name things longer in proportion to their lack of
    technical acumen. Not bad, but bad when there is a limit. :-)

    I wrote/write Korn shell, Bash, etc, for over 8 years and yes there
    are impediments, but Powershell is FAR superior in its initial release
    than anything I have seen in the windows world since Cygwin (could not
    resist a *nix plug!).

    I love it.
    L


      My System SpecsSystem Spec

Page 1 of 2 12 LastLast

Embarrassing limitation in PowerShell
Similar Threads
Thread Forum
Shrink limitation Vista General
not telling the 3GB vs 4GB limitation Vista General
Bitwise limitation PowerShell
By the way... did you know of the zune limitation? Vista General
Generics Limitation with WCF Indigo