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...

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...
>
>

> 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.

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.
>
>

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...

> 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 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
>
>
>
>
>
>
>
>
>

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

> 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.

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