Re: Prevent command prompt from popping up at system startup

That's right. I call commit on boot time because actually it doesn't
matter when you issue this command, as long as it's done before the
system reboots, of course. And the boot time seemed the easiest
solution to me.

I'll also explain why I use such an approach, maybe anyone of you has a
better suggestion how to do that and I'll be gratefull for any help.
I'm using RAM Reg mode to protect the lifetime of the CompactFlash
where the system runs. The CompactFlash is 4GB in size, whereas the
system RAM is "only" 1GB, so it could be possible to fill up the whole
RAM. But since the user will be limited in its actions, that should
never occour. With that I mean that the system will boot in a custom
shell which is an application which allows only certain actions. To
tell the truth, I haven't tested the system in a long run yet, i.e.
running for a week, but I'll do it as soon as I have the chance.

I also thought of the possibility of filling up the RAM which would
lead to a system crash, but is there any other approach to protect the
CF? Maybe to commit the overly when the system runs, but as I know
that's impossible....

Regards,
Jure


KM wrote:
My guess is...

The actual commit is going to be done on graceful shutdown/reboot.
The storage is still protected (calls are redirected to the EWF overlay). So if sudden power loss occurs, it won't break the system.

And all the changes user makes are persistent. Sometime it may be required by a system specs.

However, there is still a risk factor in such approach. If RAM overlay used, user changes, if not controlled, may easy and quickly
increase the overlay size before the current session ends (reboot). The overlay will grow unlimitedly until it eats up all the
memory. Only cure (without being able to limit EWF overlay size) is to control what users can do at run time - lock the OS, shell,
turn off all possible OS, IE and app caches, disable background disk processes like defragmentator, etc.

--
=========
Regards,
KM

Jure wrote:
Thanks for your help. I'll do what you suggested.

.

Relevant Pages

  • Re: some EWF RAM questions
    ... and I'm worried about losing the PF benefits and losing RAM ... I use EWF with RAM overlay. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Prevent command prompt from popping up at system startup
    ... Without providing users to explorer shell functionally and limiting user ability to mess with the disk under your ... you should be pretty safe from the overlay size standpoint. ... The same goes for RAM - why have some much RAM available? ... you can always force your device to reboot on a scheduled basis to make sure to "clean up" the EWF overlay. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Boot Time using HORM
    ... Get better RPM hard drive and you may get happy with the HORM time. ... 2G RAM/ AMD dual core dev machine here and it restores from hibernated state in seconds). ... I then tested it with 256 megs of Ram and it booted in a few seconds, which was much faster than the Standard Boot Time without ... But I don't see any improvement in my boot time. ...
    (microsoft.public.windowsxp.embedded)
  • Re: EWFMgrCommit question
    ... With EWF RAM Reg the overlay is going to be committed on graceful shutdown. ... safely commit the overlay and reboot the device. ...
    (microsoft.public.windowsxp.embedded)
  • [patch 39/43] x86, pat: fix PTE corruption issue while mapping RAM using /dev/mem
    ... commit 9597134218300c045cf219be3664615e97cb239c upstream. ... This commit breaks mapping any RAM page through /dev/mem, ... corrupting the PTE entry that was setup with the return attribute type. ... application mapping this RAM page through /dev/mem ...
    (Linux-Kernel)