Embarrassing limitation in PowerShell

[UNIXLVR]

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

[Don Jones [MVP]]

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" <mya...@mydom.com> wrote in message
news:%23%233HIAEk...@TK2MSFTNGP02.phx.gbl...

[UNIXLVR]

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

[Don Jones [MVP]]

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" <mya...@mydom.com> wrote in message

news:eIcWwQPk...@TK2MSFTNGP02.phx.gbl...

[Oisin Grehan]

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

[UNIXLVR]

> 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

[Don Jones [MVP]]

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" <mya...@mydom.com> wrote in message

news:O4YlgKck...@TK2MSFTNGP05.phx.gbl...

[Oisin Grehan]

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

[UNIXLVR]

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

[lrbell]

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

[Oisin Grehan]

On May 9, 12:50 pm, "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?

Hmm, well I guess later versions of robocopy (it's been a while since
I looked at) go through native APIs then. This still leaves you with
the rather nasty problem of these paths you've just created being
illegal for any software -- and there's quite a lot -- that uses win32
APIs.

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

have a read through this then -- funnily enough, you'll find most
references to this syntax from unix people trying to write
interoperability layers.. lol.
* http://www.winehq.org/site/docs/winedev-guide/x3062

btw, if you find you have problems with these new paths and legacy
software, you can use subst and/or unc tricks to shorten the path..

e.g.

path1 = c:\dir\[25 directories with 300 more chars]\path\
subst x: = c\dir\[20 directories with 200 chars]

path2 = x:\[remaining 5 dirs with 100 chars]\path\

now, path2 points to the same endpoint as path1, but it is < max_path
chars long.

You can do the same trick by sharing out the path assigned to x, and
mapping a drive to \\localhost\share\[final 100 chars]\path

- Oisin