Dua with Ewf

[Guest]

Hey Konstantine,
from this older thread,
http://msdn.microsoft.com/newsgroup...mobile-winxp&lang=en&cr=US&sloc=en-us&m=1&p=1,
If I understand right, DUA file operations (movefile/delete..etc) occure
after EWF starts on the next reboot ? If so, then when trying to replace a
file it is best to move the file then commit, but what if the app is the
shell with autorestart set? Then I can't move the app, then commit because
the app never closes. I tried resetting to autorestart in the reistry, but
it requires a reboot. how can I work around this? Disable EWF?
kevin

 

[KM]

kevin,

First, please read this updated SP2 documentation:
http://msdn.microsoft.com/library/d...derationsforusingewfwithdeviceupdateagent.asp

To update system files you can use this approach:
http://msdn.microsoft.com/library/e...UpdatingSystemFilesUsingDeviceUpdateAgent.asp

Or (in case with your shell app executable) use MOVEFILE with DAMOVEFILE_DELAY_UNTIL_REBOOT flag set
(http://msdn.microsoft.com/library/en-us/xpehelp/html/xesamMOVEFILE.asp).

In any case, you would need to commit your changes.

If you use DelayUntilReboot option, you would probably better disable EWF and then enable it on next boot with self-deleting batch
file or RunOnce command.
The batch file could be as simple as just three commands:
%SystemRoot%\system32\EWFMGR.exe -enable
%SystemRoot%\system32\shutdown.exe -f -r -t 05
del /Y <this batch file path>

Does this make sense?

In case it is too complicated, from the DUA script you can always temporarily turn off the AutoRestart (is it the registry flag?),
close your shell app, update the binaries and turn on the AutoRestart back just before the reboot (after commit).

KM

 

[Kevin]

kevin,

First, please read this updated SP2 documentation:
http://msdn.microsoft.com/library/d...derationsforusingewfwithdeviceupdateagent.asp

To update system files you can use this approach:
http://msdn.microsoft.com/library/e...UpdatingSystemFilesUsingDeviceUpdateAgent.asp

Or (in case with your shell app executable) use MOVEFILE with DAMOVEFILE_DELAY_UNTIL_REBOOT flag set
(http://msdn.microsoft.com/library/en-us/xpehelp/html/xesamMOVEFILE.asp).

In any case, you would need to commit your changes.

If you use DelayUntilReboot option, you would probably better disable EWF and then enable it on next boot with self-deleting batch
file or RunOnce command.
The batch file could be as simple as just three commands:
%SystemRoot%\system32\EWFMGR.exe -enable
%SystemRoot%\system32\shutdown.exe -f -r -t 05
del /Y <this batch file path>

Does this make sense?

In case it is too complicated, from the DUA script you can always temporarily turn off the AutoRestart (is it the registry flag?),
close your shell app, update the binaries and turn on the AutoRestart back just before the reboot (after commit).

KM

It makes fine sense. The EWF disable is what I needed, but how often can
I use it? If I disable then re-enable the EWF 2-3 times per minute
would there be any issues forseeable issues?

 

[KM]

Kevin,

......>

It makes fine sense. The EWF disable is what I needed, but how often can I use it? If I disable then re-enable the EWF 2-3 times
per minute would there be any issues forseeable issues?

But you do that once in a while, right? I mean you don't update system files and your shell app on the device very often, do you?

Anyway, if you concern about CF card it is not going to wear out just because of one system boot. Although you definitely want to
minimize the number of block writes to the card.

Also, if you device is on public network you don't want to keep it with EWF disabled for a long while. Although this may not be
important as you have to EWF commit anyway.

Personally, I prefer updates with no reboot or no more than one reboot scenario. This is to make the updates as simple as possible
and, therefore, create less bugs and mistakes So I would find a way to close the shell application properly (if it is your
application and you are able to change its source code - no problem at all), do the required file replacements, then EWF commit and
reboot.

But again, if properly set up you will get no harm disabling EWF until next reboot.

Regards,
KM

PS. When I say "disable" here, I mean "commitanddisable".