Questions about using EWF on CF

  • Thread starter Thread starter Jure
  • Start date Start date
J

Jure

Hi,

i'm configuring a system (with XP embedded) where an user application
is the shell. The application "remembers" its state (child windows size
and position, etc.) by writing it's settings to the underlying
filesystem (FS). Beside that, it has an update option where it checks
on the internet for available updates. The problem is that it should
run on a CF card. I read quite a lot (on the newsgroups and on the msdn
site) about using EWF for protecting the CF (the RAM Reg mode is
suggested as the most suitable), but i still have some basic questions
about it.

1) As i said, the user application should be able to write to the FS. I
see the advantage of using EWF in that i could delay the write to the
FS until a graceful shutdown, thus minimizing the number of writes. The
solution i thought about is performing a commit at every system
shutdown. Will that work or am i missing something? I ask that because
in the help documentation and in many articles, i saw that it's
necessary to execute a CommitAndDisable command, then reboot the
system, make the desired changes, enable the overlay again and reboot
the system another time. An example of such an article:
http://msdn.microsoft.com/library/d...allingUpdatesOnEWF-ProtectedRun-TimeImage.asp

I know that since SP2 it's possible to use the "-live" switch to avoid
the reboot of the machine, but is that enough? The fact is that the FS
management should be completely transparent to the final user, so he
shouldn't even know if he's accessing the FS directly or it's data has
been saved to an overlay.

If i sum up: i'd like to write to the CF, but at the same time i want
to minimize the number of writes. All this should be transparent to the
user. How can i do that?

2) I also don't understand why is it necessary to disable the overly to
commit the changes - isn't it enough to call commit to apply the
changes and have the overlay active for other "non-ewfmgr writes"? I
want the overlay to be always active to shield the CF card from
occasional writes. So, on every system shutdown i'd like to flush the
changes (commit) and on system restart have the EWF active again.

3) I don't know how to run the ewfmgr command at system shutdown.
Somewhere i read that it's necessary to make a shutdown script. What is
that? If this is a batch file, how can i call it on system shutdown? Is
there any possibility to enclose the command in a "more hidden" place,
e.g. in the registry (like the "Run" or "RunOnce" key in the registry
which execute on system startup)? This would be a more elegant
solution.

4) How to execute a commit if i'm not logged in as Administrator. I
read in a post that it's not possible....


Any reply would be greatly appreciated. I hope i haven't asked
questions which were already answered many times. If that's the case, i
apologize and please point me to them. Thanks in advance for any help.
 
Hello,

Since you use custom aplication have you though about solution that probably many of us use and that is to keep aplication specific
data on second FS?
You can have two partitions one with OS and program and second with your custom data. First can be protected by EWF and second can
be unprotected and managed by your app.

1. You can perform commit and every system start up instead of shutdown. And if/when gracefull shutdown occur data will be written
to disk.
No need for commitanddisable jsut commit will do the job fine.
Article example is probably generic solution since it is unknown how much overlay memory space is needed when updating OS and how
much space you have. In your case you exactly know how much mem you have and how much you will use on overlays.

2. commit alone will be jsut fine, but you should try to avoid this also if possible with usage of second partition.

3. I would execute it from custom service.
4. It is not possible but having made simple service you can give commands to your service that will carry operation in your behalf.

Regards,
Slobodan
 
Hi Slobodan,

first, thank you very much for your reply.

Since you use custom aplication have you though about solution that probably many of us use and that is to keep aplication specific
data on second FS?
You can have two partitions one with OS and program and second with your custom data. First can be protected by EWF and second can
be unprotected and managed by your app.
Click to expand...

I thought about that solution, but there are (on my opinion) two
problems:
1) The application writes to the registry and to the Windows system
folder. I discovered that indirectly by trying to run the application
update from a non-administrator account. It didn't work. Then i used
FilemonNt and RegmonNt to monitor the activity. I discovered that the
application updater needs access to the Windows folder and to the
registry (i'm not sure if it accessed the HKEY_LOCAL_USER branch, which
hive is in the user's home directory, or some system branch). Another
consequence of that fact is that the user account from which the
application is run, must have administrative privileges. Is there any
possibility to avoid that?
2) The reason i use CF is the resistance to shocks, so the use of a
hard drive isn't an option. Said that, the only solution would be to
partition the CF card in two partitions or have two CF cards. In either
case i would write to a CF media and not on a hard drive, which is what
i want to avoid. Is there maybe another solution which i haven't
thought about? Do you have maybe any experience on the sensivity of the
CF media to write operations? The fact is that i didn't consider the
option of using CF without EWF. Maybe it would work....or not?

1. You can perform commit and every system start up instead of shutdown. And if/when gracefull shutdown occur data will be written
to disk.
Click to expand...

How do you mean on system startup if i use RAM Reg mode? Aren't the
changes lost on system shutdown if i don't commit them?
No need for commitanddisable jsut commit will do the job fine.
Article example is probably generic solution since it is unknown how much overlay memory space is needed when updating OS and how
much space you have. In your case you exactly know how much mem you have and how much you will use on overlays.

2. commit alone will be jsut fine, but you should try to avoid this also if possible with usage of second partition.

3. I would execute it from custom service.
Click to expand...

Maybe any link on an example or a tutorial? I'm completely new in that
field. (If there is any tutorial for Delphi, much better :-)
4. It is not possible but having made simple service you can give commands to your service that will carry operation in your behalf.
Click to expand...

As above, do you maybe have any link for that problem?
Regards,
Slobodan
Click to expand...

Thank you again for your answers.
 
Jure,

2. You can try using flash medium with wear leveling driver or build in technology. Ordinary CF do not have a chance for very long
life if you do not protect OS partition.
How do you mean on system startup if i use RAM Reg mode? Aren't the
changes lost on system shutdown if i don't commit them?
Click to expand...

Well when you "commit" change if will tell driver to set one flag bit nothing more. During the gracefull shutdown driver will test
that flag and decide whether to commit changes or to discard data from overlay. So no matte when or how many times you do commit
operation during the XPe run time it will be done only once on data present after the FS is closed and all data as stable in
Overlay.
Maybe any link on an example or a tutorial? I'm completely new in that
field. (If there is any tutorial for Delphi, much better :-)
behalf.

As above, do you maybe have any link for that problem?
Click to expand...

No. But you can find some examples in MSDN and doc about writing services. (Try avoiding Delphi for this purpose.)

Regards,
Slobodan
 
Hi Slobodan,

after re-reading your first post, another question emerged. You said:

"Article example is probably generic solution since it is unknown how
much overlay memory space is needed when updating OS and how much space
you have. In your case you exactly know how much mem you have and how
much you will use on overlays."

I only want to know if i understood right your answer. You mean that
the reason of disabling the EWF prior to making any updates is that if
an update is large in size, it's possible that you run out of memory
(because of lot of written data), hence for a general solution, the
best approach is to disable the EWF (that way you can't run out of
memory).

I ask that because i beacame curious when reading "....and how much you
will use on overlays.....".
You mean that i know how much i'll use on overlays by considering the
size of the CF (or better the used space on the CF if defragmentation
and such tools are disabled, so that i access only the real data)? I
mean, you can't fix the maximal amount of memory avalable to the EWF.
EWF allocates the memory when it needs to until the system runs out of
memory (in case a lot of different data is written), right?
 
Back
Top