semipermanent instead of only one command

[Carsten Krüger]

Hi,

instead of:
shadowspawn [ /verbosity=LEVEL ] <src> <drive:> <command> [ <arg> ... ]
where I can only run one command, I'd like to have something similar to net command:
net use x: \\server
and
net use x: /delete

for exmaple:
shadowspawn [ /verbosity=LEVEL ] <src> <drive:> [ /command <command> [<arg> ... ]] [ /delete]

now:
shadowspawn C:\foo Q: robocopy Q:\ C:\bar /s

later:
shadowspawn C:\foo Q: /command robocopy Q:\ C:\bar /s

or

shadowspawn C:\foo Q:
robocopy Q:\ C:\bar /s
shadowspawn Q: /delete

[Craig Andera]

So, that's an interesting proposal. It would require specifying what
are called persistent shadow copies. Persistent shadow copies are only
possible against NTFS, and don't work on Windows XP, so that would
break our cross-OS support story, or at least require us to document
the different behaviors.

If I were going to do this, I would probably take the approach of
splitting ShadowSpawn into a library for working with shadow copies
and two executables: one that would be what shadowspawn is now, and
one to do what you want. I tend to prefer tools that just do one
thing.

There are two ways to achieve what you are after with existing tools:

1) Launch cmd.exe instead of hobocopy, and use the /c switch to
specify a batch file. The batch file can have as many commands as you
want in it.
2) Use vshadow.exe - I'm pretty sure it does what you want to already.

I've captured this as a feature request in the project issue tracker.
See https://github.com/candera/shadowspawn/issues/13

Thanks for the suggestion!

2011/9/19 Carsten Krüger <C.Kr...@gmx.org>:

[Carsten Krüger]

Hello Craig,

> So, that's an interesting proposal. It would require specifying what
> are called persistent shadow copies.

No, i do not mean persistent ones ;-)
That's why I wrote semipermanent, it would be perfectly ok if the copy
didn't survive a reboot.

---------------sleep_forever--------------
using namespace System;
using namespace System::Threading;

int main()
{
Thread::Sleep(Infinite);
}
---------------sleep_forever--------------

call shadowspawn c:\foo q:\ sleep_forever.exe

robocopy Q:\ C:\bar /s

taskkill /IM sleep_forever.exe

It would do what I mean (I think), but it's not "nice".

> There are two ways to achieve what you are after with existing tools:

> 1) Launch cmd.exe instead of hobocopy, and use the /c switch to
> specify a batch file. The batch file can have as many commands as you
> want in it.

That didn't help, many programs didn't "block" but spawn another
process and end themselves.

greetings
Carsten

[Carsten Krüger]

> call shadowspawn c:\foo q:\ sleep_forever.exe
> robocopy Q:\ C:\bar /s
> taskkill /IM sleep_forever.exe

> It would do what I mean (I think), but it's not "nice".

call is wrong, I mean start.

start shadowspawn c:\foo q:\ sleep_forever.exe
ping 127.0.0.1 -n 20

robocopy Q:\ C:\bar /s
taskkill /IM sleep_forever.exe

The sleep (ping for 20 seconds) is needed because the shadow copy
needs time to be created.

I've tested it and it works.

greetings
Carsten

[Craig Andera]

>> So, that's an interesting proposal. It would require specifying what
>> are called persistent shadow copies.
>
> No, i do not mean persistent ones ;-)
> That's why I wrote semipermanent, it would be perfectly ok if the copy
> didn't survive a reboot.

Well, I find the VSS documentation confusing at the best of times, but
my understanding is that shadow copies are either persistent or not.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa384613(v=VS.85).aspx.
If they are persistent, they survive a reboot and take up disk space,
just like system restore points (which I believe are also done using
VSS).

We could, however, mount the drive letter in such a way that it would
go away at the next reboot. That would still require a persistent
shadow copy, since it would have to survive past the end of the shadow
copy process. In that event, I would probably still want to provide a
second tool that does that, since I'm not a fan of "Swiss Army knife"
tools that do lots of stuff. I'd rather have two tools that each do
one thing than one tool that does two things.

It's entirely possible I'm missing something, of course. :)

> call shadowspawn c:\foo q:\ sleep_forever.exe
> robocopy Q:\ C:\bar /s
> taskkill /IM sleep_forever.exe
>
> It would do what I mean (I think), but it's not "nice".

What's the particular use case you're after? Do you have some command
in particular that you want to launch that is exiting and causing
shadowspawn to tear down the shadow copy? If that's the case, then
perhaps the right thing to do is not to make the shadow copy live past
shadowspawn, but just to get shadowspawn to stop terminating before
all its descendant processes do.

Can you say more about the problem you're trying to solve?

[Carsten Krüger]

Hello,

> Well, I find the VSS documentation confusing at the best of times, but
> my understanding is that shadow copies are either persistent or not.

ok, technically I mean a non persistent copy.

I'd like to have the ability to run more than one command.

> It's entirely possible I'm missing something, of course. :)

I'd like to have a pendant to
net use (mounted drive lives until reboot)
but not "net use /PERSISTENT" (mounted drive lives forever)

> What's the particular use case you're after?

a) I could do error handling myself (check for error code of launched
command(s))
b) I can "browse" the snapshot manually.

It's no big problem if you think that's not a good feature.

greetings
Carsten

[Craig Andera]

> ok, technically I mean a non persistent copy.
>
> I'd like to have the ability to run more than one command.
>

> I'd like to have a pendant to
> net use (mounted drive lives until reboot)
> but not "net use /PERSISTENT" (mounted drive lives forever)
>
>> What's the particular use case you're after?
>
> a) I could do error handling myself (check for error code of launched
> command(s))
> b) I can "browse" the snapshot manually.
>
> It's no big problem if you think that's not a good feature.

It's not that I don't think it's a good feature, it's that I had
thought people would use cmd files to achieve it. If that doesn't work
for some reason, I definitely want to hear about it. You mentioned
that some commands return immediately after launching subprocesses -
that's an interesting case. Is that the primary roadblock you're
encountering?

And it's sort of a hack, but when I want to browse the snapshot
manually, I usually just launch notepad.exe as the command and do a
File->Open to check out the state of the filesystem. For some reason,
we don't always see the mounted drive in Explorer.