Robocopy doesn't play well with Powershell.
Tim Munro
I've noticed that Robocopy and powerhshell don't play well together. By
Example is the best way to demonstrate.
I have the C: drive set to a folder (C:\Temp\test)
I have a networked drive R: set to a folder R:\Scripts\testing
I'm sitting in PS on the R: drive in the testing folder.
If I DIR C: I get the correct listing. (DIR C:)
If I copy a file from C: I get the expected file. (copy C:filename)
However if I use robocopy I get the ROOT of C:
EG: Robocopy C: R: *.xls (for example) It will search for XLS files on the
root of C: and NOT in the folder C: is set to.
Most frustrating. Any ideas or comments?
--
Tim.
Chris Dent
You could work-around it by using this for the "other" path:
$(Get-Item C:).FullName
Get-Item has no problem picking up the correct path (as you found when
you used Get-ChildItem / dir).
Chris
Alex K. Angelopoulos dot dot again at
assume you set PowerShell's location on the C drive; this has no effect on
the current working directory for the PowerShell process with respect to
that drive.
You can use the System.Environment's static CurrentDirectory property to
inspect and set this value if you really need to; in cases like simplifying
Robocopy use it can be handy:
[environment]::CurrentDirectory
to get the current directory
[environment]::CurrentDirectory = "C:\temp\test"
to set it
"Tim Munro" <Exce...@Liamtoh.moc> wrote in message
news:upfSrt5C...@TK2MSFTNGP03.phx.gbl...
Tim Munro
best for Robocopy command typing.
--
Tim.
"Alex K. Angelopoulos" <alex(dot) k(dot again)angelopoulos(at)gmail.com>
wrote in message news:eBu%236u6CK...@TK2MSFTNGP03.phx.gbl...
Joel Bennett
You can work around it by putting that in your PROMPT function so it
gets updated every time you do anything:
[Environment]::CurrentDirectory = pwd
--
Joel
Alex K. Angelopoulos dot dot again at
dust settled, the current default behavior was explicitly chosen as part of
the "secure by default" philosophy. Here's why it matters - it's a bit
obscure, but it's rooted in the security problems with Windows' own handling
of path search.
Suppose working directory _did_ follow location. We set the location to a
particular folder x:\bad\mojo which has been compromised and contains some
binary exploits, including trojans masquerading as the popular angst.exe and
ennui.dll. We then launch the non-PowerShell application foo.exe.
Since PowerShell's command search doesn't include working directory as a
path element, there's no chance of the x:\bad\mojo\angst.exe being loaded by
accident; instead, we get the c:\apps\console\angst.exe that's in our
explicit search path.
However: the file c:\apps\console\angst.exe automatically tries to load
certain DLLs if present - for example, ennui.dll. It's search for this DLL
will begin in x:\bad\mojo, since that's the working directory. So it still
ends up loading exploit code.
So it's not obvious, but setting working directory to follow location would
be a security hole (albeit a pinhole).
"Joel Bennett" <Jay...@HuddledMasses.org> wrote in message
news:#WyY8HAD...@TK2MSFTNGP02.phx.gbl...
Joel Bennett
That's preposterous.
Not only is the change of attack through that method diminishingly
small, the current situation does NOTHING to fix that: if PowerShell
did, in fact, force the CurrentDirectory to a "protected" spot in
Program Files or C:\Windows ... I would almost buy that as a reason.
But setting the CurrentDirectory arbitrarily to the user's home
directory ( %HOMEDRIVE%%HOMEPATH% ) by including it in the launch
shortcut is, if anything, *more* likely to encounter "exploit code"
assemblies than just letting it follow the PowerShell location. After
all, you just gave attackers a map: please put your exploits in the
user-writable HOMEPATH location, or convince the user to change their
shortcuts to start in your exploited location...
Much better to have it follow the PowerShell pwd, and at least BEHAVE
THE WAY USERS EXPECT YOU TO BEHAVE, instead of behaving arbitrarily bad.
Particularly since the actual (initial) CurrentDirectory changes
depending on how you launch PowerShell.
Bob Landau
MyApp.EXE (Resolve-Path c:)
What I don't understand is just why has anyone else not experienced this????
I've been using Powershell for several years and have never seen this issue
when using a relative path as a parameter for either cmdlets and native
commands or applications.
Frankly I believe the problem is more with what RoboCopy is doing than
anything else.
For those that want some insight into what is going on try this
CD <drive>:<path> ## for example c:\temp\foo
PWD . or PWD <drive>: ## either will print out c:\temp\foo
[io.directory]::getcurrentdirectory() ## prints out current directory set by
CreateProcess() or explicitly by Poweershell i.e. c:\users\robertla
Copy c:\junk\test.txt c:\temp\foo ## copy a text file to the test folder
## create a test drive and move to it
New-PSDrive -Name t -Root $home\documents\pictures -PSProvider filesystem
CD t:
## Verify that the text file is in the current directory of Powershells
Filesystem provider
PWD c:
DIR c:test.txt
## now trace out how the path is resolved.
Trace-Command -Name PathResolution -Expression {notepad c:test.txt} -pshost
The current directory or home directory for the process doesn't or shouldn't
matter. If it did or as in your case evidently does I like Joel consider this
to be a bug. If this can be verified using another application other than
RoboCopy file a bug and paste in the output from the trace above.
Alex,
What I believe you're speaking about is specific to whether a program should
be launched in the current directory _unless_ it is explicitly stated. When
it comes to loading DLL's the current directory has been one of the last
directories searched by LoadLibrary since W2k.
bob
Alex K. Angelopoulos dot dot again at
news:6C255F77-8EEC-4FC9...@microsoft.com...
> Tim another method around this is
>
> MyApp.EXE (Resolve-Path c:)
>
> What I don't understand is just why has anyone else not experienced
> this????
>
> I've been using Powershell for several years and have never seen this
> issue
> when using a relative path as a parameter for either cmdlets and native
> commands or applications.
The path expansion behavior really does seem to insulate native apps. I've
had to deal with the problem when directly reading/writing files using the
.NET framework, but that's pretty atypical. And I hadn't thought about it,
but you're right about it being RoboCopy - the expansion of a drive spec to
the current directory on that drive is essentially special syntactic
sweetener.
> Frankly I believe the problem is more with what RoboCopy is doing than
> anything else.
(snipped - see Bob's post for the handy demo of location-versus-working
directory)
Alex K. Angelopoulos dot dot again at
> That's preposterous.
I know, I know. That was my initial reaction to it back when - and also to
some details like PS shipping with scripting disabled, for essentially the
same reasons. Some other comments inline. _DO_ note that this is simply what
I recall at this late date; the conversations I was involved in about it
were a good 3 years ago, and I may be mis-stating some aspects of the
rationale.
> Not only is the change of attack through that method diminishingly small,
> ...
I know, but it would still be considered a flaw. Part of it is that one of
the rigid internal design requirements of PowerShell was that defaults
should be totally secure, even if inconvenient - thus decisions like
shipping with script execution disabled. I don't recall people hashing out
all of the details of the problem area, but this smells like that kind of a
decision. It's more secure than directory-following, albeit annoying - but
it's possible for someone who knows what they're doing to loosen the
behavior, using the method you describe.
> ... the current situation does NOTHING to fix that: if PowerShell did, in
> fact, force the CurrentDirectory to a "protected" spot in Program Files or
> C:\Windows ... I would almost buy that as a reason.
>
> But setting the CurrentDirectory arbitrarily to the user's home directory
> ( %HOMEDRIVE%%HOMEPATH% ) by including it in the launch shortcut is, if
> anything, *more* likely to encounter "exploit code" assemblies than just
> letting it follow the PowerShell location. After all, you just gave
> attackers a map: please put your exploits in the user-writable HOMEPATH
> location, or convince the user to change their shortcuts to start in your
> exploited location...
Actually, that doesn't make it any easier to introduce exploits; it makes it
harder. If an attacker can copy files to a user's home directory, they've
already got sufficient privileges to act on the user's behalf directly. The
intent is, as I recall, to mitigate the exposure when traversing shared
network locations where other users - quite possibly legitimate users - may
put exploit code, intentionally or not. For someone to put code in your home
directory, however, you would already need to be compromised.
> Much better to have it follow the PowerShell pwd, and at least BEHAVE THE
> WAY USERS EXPECT YOU TO BEHAVE, instead of behaving arbitrarily bad.
> Particularly since the actual (initial) CurrentDirectory changes depending
> on how you launch PowerShell.
I know. I have my own serious problems with this whenever I try to leverage
native tools or APIs that work with files. But approaching it as a bug isn't
going to work very well - it will just get a bug report stamped "by design -
closed". ; )
This is one of the nastier odd pinch points in PowerShell (although I still
think Get-ChildItem's odd behavior in certain situations is the all-time top
problem).
Tim Munro
Robocopy (resolve-path C:) (resolve-path R:) *.xls switch switch log...
It should behave as one would expect in the good olde CMD world? This seems
by far the easiest and most self-documenting solution.
Thanks Bob.
--
Tim.
"Bob Landau" <BobL...@discussions.microsoft.com> wrote in message
news:6C255F77-8EEC-4FC9...@microsoft.com...
Roman Kuzmin
> It should behave as one would expect in the good olde CMD world? This seems
> by far the easiest and most self-documenting solution.
FYI. Resolve-Path does not get what you normally want for network
paths, e.g.
> resolve-path '\\DEV-XXX\C$\'
Microsoft.PowerShell.Core\FileSystem::\\DEV-XXX\C$\
which will not be recognized by Robocopy.
Bob Landau
Powershell treats rooted paths (net use/new-psdrive) and unrooted paths
differently.
while not as convenient as the Path property this works
(resolve-path '\\DEV-XXX\C$\').ProviderPath
or
(resolve-path c:).ProviderPath
as long as the application understands UNC paths it will work
Bill Stewart
> This is one of the nastier odd pinch points in PowerShell (although I
> still think Get-ChildItem's odd behavior in certain situations is the
> all-time top problem).
Fascinating discussion, gentlemen.
Alex: I am curious about "Get-ChildItem's odd behavior in certain
situations" -- can you enlighten?
Thanks!
--
Bill Stewart
Joel Bennett
Tim Munro
below the share name and all.
Why would you want to resolve the path of a path? (Resolve-Path
'\\Server\Share$\folder') as the path is already given. Seems redundant to
me.
So
PS>Net use T: \\Server1\Share$\folder1
PS>(Resolve-Path T:) gives me T:\
PS>cd T:\folder2
PS>(Resolve-Path T:) gives me T:\Folder2 just as I would have expected.
--
Tim
"Bob Landau" <BobL...@discussions.microsoft.com> wrote in message
news:F62C3DF3-1AA1-4173...@microsoft.com...
Alex K. Angelopoulos dot dot again at
news:#V2h02sD...@TK2MSFTNGP03.phx.gbl...
One caveat - I meant _apparent_ odd behavior. Get-ChildItem can be very
confusing to new users, primarily due to expectations based on other tools
(and that it superficially appears to work like other tools). Note that most
of this got hashed out endlessly during beta, and no one came up with a
better approach; in fact, some of the oddities of the current design are
actually guard rails against problems.
(1) -Path wildcards:
Since you can do
gci c:\windows\*.exe
it looks like Get-ChildItem supports filtering syntax like that of the dir
command. That's only true without recursion, since you're specifying a path
filter with that c:\windows\*.exe. So the equivalent to cmd.exe's
dir c:\windows\*.exe /s
is really
gci c:\windows -include *.exe -recurse
and it takes time for people to understand why
gci c:\windows\*.exe -recurse
doesn't work.
There was no reasonable fix for this that wouldn't nerf Get-ChildItem or
make wildcards too complicated to use. The underlying issue is expectations
driven by the way recursive filtering works in other shells.
-Filter syntax and priority:
The -Filter parameter. It's a provider-native filter, which means when used
with filesystem filtering, the wildcards don't work the way they do in
Include/Exclude. It trips people up at two points - when they start using it
after using the PS-native filtering parameters or when they try using it
with other providers such as the Registry provider. However, we need -Filter
as a workaround for filtering tasks that would otherwise take forever.
There are other minor expectation issues, but they're all pretty much rooted
in the fact that Get-ChildItem has to work for any arbitrary provider, and
in order to do so it can't do things that people are used to from the DIR
command. As an example, people initially often expect to see registry values
returned as items when enumerating the registry, instead of needing to go
through the messy ItemProperty processing. In fact, in beta PowerShell
returned registry values as actual items. This was incredibly convenient,
except when it broke, and then it was awful.
The problem comes down to the fact that unlike filesystem items, registry
items don't have a single-name specification (this is why WScript.Shell's
RegRead and RegWrite can't do some things). Consider the following registry
path:
HKLM\software\Microsoft\Windows
This is a well-known registry key. However, if values as well as containers
were items, we couldn't disambiguate the key from the default value of
HKLM\Software\Microsoft\Windows, nor from a value under
HKLM\Software\Microsoft which has the name Windows. One idea was to use a
terminal "\" to mark the key, but "\" is also a legal valuename. There could
also be a legal value named Microsoft\Windows under HKLM\Software.
So, in my opinion it's an awful mess. Unfortunately, there's not much that
can be done better for a provider-agnostic item enumeration tool.
Bob Landau
Bob Landau
I suspect there isn't a good reason using Resolve-Path if the path is
\\server\share\folder\...
If all your work is on the command line then you can make the runtime call
of whether to call it or not.
However if a script passes in a path and you need to support both
\\server\share\folder\...
and
C: ## Where the location was set as Set-Location c:\temp
then you would. As you found out
1) for some reason RoboCopy is not using the folder that is expected.
2) Roman pointed out that UNC names resolve to
Microsoft.PowerShell.Core\FileSystem::\\DEV-XXX\C$\
Lastly Joel mentioned that piping the output from Resolve-Path to
Convert-Path solves both 1) and 2)
Tim Munro
In my particular case it is all command line driven. It is good to know that
all cases can be resolved properly in a script if/when necessary. Good
discussion folks and thanks very much for all your input.
--
Tim.
"Bob Landau" <BobL...@discussions.microsoft.com> wrote in message
news:0EC9DB26-5C2B-46D0...@microsoft.com...
Bill Stewart
Alex K. Angelopoulos wrote:
> One caveat - I meant _apparent_ odd behavior. Get-ChildItem can be very
> confusing to new users, primarily due to expectations based on other
> tools (and that it superficially appears to work like other tools). Note
> that most of this got hashed out endlessly during beta, and no one came
> up with a better approach; in fact, some of the oddities of the current
> design are actually guard rails against problems.
>
> (1) -Path wildcards:
> ...
>
> -Filter syntax and priority:
> ...
>
> There are other minor expectation issues, but they're all pretty much
> rooted in the fact that Get-ChildItem has to work for any arbitrary
> provider, and in order to do so it can't do things that people are used
> to from the DIR command.
> ...
> So, in my opinion it's an awful mess. Unfortunately, there's not much
> that can be done better for a provider-agnostic item enumeration tool.
Hi Alex,
Thanks for the great summary. I was already aware of these oddities, but
it is still helpful for new PoSH users who have run into them.
--
Bill Stewart
Gerry Hickman
> So, in my opinion it's an awful mess.
LOL, this part I _have_ to agree with:)
--
Gerry Hickman (London UK)