copy-Item with different providers

Hi All,

I'm writing a DeviceFilesystem provider, that is using RAPI to expose a
device connected via ActiveSync as a Powershell drive.

I'm having trouble figuring out the best way to handle copies from the
device to the pc and vice versa.

Is there a standard way to do this?

Say for example I'd like to do the following:

Copy a file log.txt from \storagecard\ on the device to a folder c:\logs on
the PC.

1. Should I write my provider with some heuristics to find out if the path
is located on the PC or on the device?
ie: Copy-Item -path: \StorageCard\log.txt -destination:
C:\Logs\log.txt
2. Should I demand that all PC paths are qualified with the provider
(Microsoft.PowerShell.Core\FileSystem:?
ie: Copy-Item -path:
DeviceUtil\DeviceFileSystem::StorageCard\log.txt -destination:
Microsoft.PowerShell.Core\FileSystem::C:\Logs\log.txt
3. Is there any way to get the above Copy-Item example to work if my
current location is not in the DeviceFileSystem provider?
PS C:\ > Copy-Item -path:
DeviceUtil\DeviceFileSystem::StorageCard\log.txt -destination:
Microsoft.PowerShell.Core\FileSystem::C:\Logs\log.txt

Thx,

Staffan

Hi
have you seen the info at

http://msdn2.microsoft.com/en-us/library/ms714636.aspx

and subsequent sections
--
Richard Siddaway
Please note that all scripts are supplied "as is" and with no warranty
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Staffan Gustafsson" wrote:

On Nov 19, 7:43 am, "Staffan Gustafsson"
<staffan_no_spam_.e.gustafs...@xxxxxx> wrote: Hi Staffan,

Unfortunately cross-provider copying is not possible in PowerShell
v1.0 using the stock *-item cmdlets; nor have I heard any twittering
from the big house regarding its arrival in 2.0 either. It's early
days though. Speaking of, many moons ago during (very) early betas of
Monad/PowerShell I was in your position and had opportunity to ask
someone on the posh team about this and iirc, I was told that many
ideas about how to do it were thrown about internally but nothing
really worked well enough to warrant the time and effort on it, and it
was placed on the "argh!" list.

The only two interfaces that provide data reading and data writing
that are common to providers are IContentReader and IContentWriter,
which are obtained for reading and writing to/from items in a provider
that implements IContentCmdletProvider. While it looks nice in theory,
in practice I've found it to be a pain; I found myself wishing for a
IContentStreamReader / IContentStreamWriter that would let you expose
Streams instead, since often you're manipulating one under the covers
anyway; Streams come with their own baggage too I guess though, in the
sense that you're forced to implement quite a number of members, some
of which may or may not make sense for you (async read/write for
example).

So ultimately, you might think of creating some cross-provider cmdlets
specialising in "connecting" the ContentReader and ContentWriter ends
of two provider paths; I know I did, but some initial tests proved it
to be prohibitively slow. I suspect this is what the Posh team found
too, and decided it would be too damaging to the perception of posh's
speed -- already a thorny point as it is -- and instead choosing to
push it for v2 (we hope).

- Oisin / x0n

p.s. how are you finding that RAPI stuff? painful, isn't it? I have a
very similar project in flux up on codeplex at the moment:
www.codeplex.com/psmobile - perhaps we could join forces?

Hi Steffan;

PowerShell doesn't support copying items between providers. It probably
makes sense for copying between the FileSystem provider and other providers,
but not between arbitrary providers. If you want to bring files from the
device to the filesystem, you can write cmdlets to do that.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Staffan Gustafsson" <staffan_no_spam_.e.gustafsson@xxxxxx> wrote in
message news:e6lVRnqKIHA.2064@xxxxxx

Hi Lee,

That sounds pretty authoritative then - so no interfaces for cross-
provider copying on the agenda for v2? v3? The copy metaphor needn't
mean a perfect facsimile in object terms, since obviously providers
and their backing stores can vary vastly - but some kind of generic
hook would be nice?

Alternatively, if you were to push the FileSystemProvider a little
deeper, and instead expose:

NavigableCmdletProvider
FileSystemProvider (abstract - expose filesystem friendly abstract
methods here)
WindowsFileSystem (powershell core)
MyDeviceFileSystem (3rd party)
Ext3FileSystem (3rd party)

etc...

You could provide simple Transform stub methods, or go crazy and allow
windows workflow / biztalk style transform pipelines. Maybe the
FileSystemProvider should serialize items a la export-clixml for
marshalling, allowing even a simple xslt transform to massage an
object before deserializing a la import-clixml on the other side and
writing out the data...

anyway, I'm rambling here, perhaps this should be on connect whereby
people can shoot me down in a more formal environment ;-)

Thoughts?

- Oisin "x0n" Grehan
http://ww.nivot.org - http://oisin.powershell.com





On Nov 19, 12:32 pm, "Lee Holmes [MSFT]"
<leeh...@xxxxxx> wrote:

I personally thing just as you have adapters to convert/cast a variety
of class types..

it would be great if there was a way you could register classes that
will convert between objects used in providers.. so that if a class was
registered that could do the conversion, you could use

copy-item

just my thoughts

-Karl

On Nov 19, 4:37 pm, "Karl Prosser[MVP]" <karl@xxxxxx_o_w_e_r_s_h_e_l_l.com>
wrote: Yep, or even just piggyback on the standard PSTypeConvertor classes
that are used for casting, although the destination type would have to
be declared ahead of time in the case of ambiguity.

- Oisin

Of course I can write commandlets to do it, but you have to admit it's not
an elegant solution.

As a concept, there is no difference between a removable drive, a remote
drive and a RAPI connected drive, so it would be nice if we were able to
expose it in some natural way.

Does it sound infeasible to let the devicefilesystem have some knowledge of
the filesystem provider, and use qualified paths if there are ambiguities?

/Staffan

"Lee Holmes [MSFT]" <leeholm@xxxxxx> skrev i meddelandet
news:4741c8c0$1@xxxxxx