EvfMgr C: -commit followed by Power Down gives lost changes

  • Thread starter Thread starter Lasse
  • Start date Start date
L

Lasse

Hi All
I use "EwfMgr C: -commit", and a short time after that the power is
turned off. What should happen ?

I thought that -commit made the changes to be flushed to the disk.
But it seems to me that there is some kind of delayed write to the disk.
Turning off the power makes the changes to be lost.
If I make a graceful shutdown, everything works OK.

If I am right, is there some utility or API I can use to flush
everything to the disk after commit.

Lasse
 
Lasse,

commit is just a notification to driver that it should save data from overlay to disk.
If you are talking about RAM EWF then this save happens only during the graceful shutdown, not before.

Regards,
Slobodan
 
Thanks for the answer.
Yes, I am using RAM EWF.
I will try using Sync.exe from SysInternals to solve my problem.

Lasse
 
Hi Lasse,

What do you mean by that? Could you explain?

Regards,
Slobodan
 
Hi
My problem is that the (some) users of the system sometimes makes commit
then reboots the by turning power off/on (it is much easier).

My intention is to create a file Commit.bat that does:
C:\SomeSecretDir\EwfMgr C: -commit
Sync C: # flush

Meaning the users can only use the commit.bat file that flushes the disk.

Sync (www.sysInternals.com)
UNIX provides a standard utility called Sync, which can be used to direct the
operating system to flush all file system data to disk in order to insure that
it is stable and won't be lost in case of a system failure. Otherwise, any
modified data present in the cache would be lost. Here is a an equivalent that
I wrote, called Sync, that works on all versions of Windows. Use it whenever
you want to know that modified file data is safely stored on your hard drives.

Will this work.
Could this function be above the EWF and not operate on the disk ?

I have a SanDisk FlashDisk, NTFS, compressed, 60 Mbyte.
commit is only used for some change of settings and update of applications.
 
Hi Lasse,

I asked because I though that you will try to use such approach, but I will disappoint you.

RAM EWF overlay content is only written during the graceful shutdown (Or in SP2 if you commitanddisable overlay with live switch).

EWF is between disk driver and filesystem driver. So flushing FS will just move data to EWF overlay, but data will stay there and
will not go to physical disk.

Regards,
Slobodan
 
Hi Slobodan
Thank you for the information.
Seems to me that the only secure method is to make a graceful shutdown
directly after commit. (if there is any chance for power failure or
someone turning power off).
Turning power off is our normal method to shutdown our system.

The problem is that some changes might be saved and others not.
This might be difficult to detect.

Lasse
 
Hi Lesse,

I did not understand your last question about the power off, could you elaborate what you want to do?

With RAM EWF turning power off is ok thing to do. But settings will be lost.
You can move settings to second unprotected partition.
The problem is that some changes might be saved and others not.
This might be difficult to detect.
Click to expand...

What do you mean by that?

Regards,
Slobodan
 
Lasse:

After the commit then force a restart using:

shutdown -r -t 0

You can add this in your bat file after the "ewf C: -commit"

HTH... Doug
 
Hi Slobodan
Here a better description of my problem
Most of the PCs in my system are headless. (not possible to connect a screen).
The only connection is ethernet and USB.

When we want to update/install a PC with new application software,
a little utility on this PC is started from a remote computer. This uses
a script and connects to an external WebServer to fetch the new software.
This might include running a script that modifies Registry, deletes files, ...

Some files goes to unprotected D: (NTFS), some to protected C:
If something is written to C:, my utility makes EwfMgr C: -commit.

My intention was that the user should initiate a graceful shutdown
after that. (This can be done from an external computer).

But the users does not allways follow that rule. They turn off the power.

Sometimes it could be lots of new files. My guess is that when
there are lots of files, some are flushed to the physical disk, some not,
causing an inconsistent system. (if someone turns off power).

Normally (no updating is done) nothing is written to any of the partitions.
The way to stop is to turn off power.

Lasse
 
Hi Lasse,
When we want to update/install a PC with new application software,
a little utility on this PC is started from a remote computer. This uses
a script and connects to an external WebServer to fetch the new software.
This might include running a script that modifies Registry, deletes files, ...
Click to expand...

Where is the EWF in this utility, I do not see that it is connected to your image per your description.
If EWF is not active in this remove OS then you can update any files without committing them.

Regards,
Slobodan
 
Hi
This is how I do things.
The Target Designer image contains only the OS and some utilities
for remote installation of our applications.
The image is developed on a development PC with screen.
This is put as a Ghost image on a DOS bootable CD.
We install it on the headless machines by booting from an USB CD reader.
(the first boot device). DOS automatically runs Ghost.
After that we remove the CD and reboots. Up comes XPE, which the first
time uses an utility to fetch the applications from an external Webserver.
There are more than 50 applications.

One reason for not making Target Designer components and include
the applications in the image is that XPE is developed before the
applications and they are changed many times during the development phase.
When the applications are changed the method mentioned below is used.

Another reason is that the PCs use the same Target Designer image
but different applications and settings.

We are not using cloning tools since I see no reason for that.

By the way, one little problem is that I want to eject the USB CD
from DOS when Ghost is completed so I know when I can reboot the PC.
I have no idea how to do that. I guess this is a matter of BIOS support
when an USB CD reader emulates a hard disk.

As you can see EWF is there all the time.
 
Lasse,
By the way, one little problem is that I want to eject the USB CD
from DOS when Ghost is completed so I know when I can reboot the PC.
I have no idea how to do that. I guess this is a matter of BIOS support
when an USB CD reader emulates a hard disk.
Click to expand...


I am not sure about USB CD-ROM but with regular CD-ROM you could just use INT 21 (AX=4403: Send CD Control Data) commands to send
the eject control signal. The control block 0, IIRC.
Or just use a complied tool like: ftp://ftp.simtel.net/pub/simtelnet/msdos/cdrom/cdromcmd.zip. Btw, there are sources that you can
leverage to create your own tool that does the job. Sources are in Pascal - really easy to read. The pieces you are going to be
insterested in - in assember and easy to read as well.
 
Hi Lasse,

Sorry but I do not see where is EWF in this story?
EWF would be active only while you do update from inside of XPe , but then you can commit and reboot computer trough update program
and everything would be ok.

Regards,
Slobodan
 
I was about to suggest the same thing, after all, it only takes just a few
seconds longer than flipping a power switch.
 
Lasse:

For ejecting the CD, how about using ejectcd.com? I've used this for a
regular ATAPI CD-ROM. Not sure about a USB CD-ROM.

HTH... Doug
 
Hi
I tested cdromcom.zip as you suggested.
It did not work at once. I assumed it was because DOS sees the USB CD-ROM
as a hardisk since the bootable CD emulates a hard disk (it is C:).
Then I started "duse".
(This is a freeware software packet that supports USB from DOS).
Now DOS sees the USB CD-ROM as a normal CD-ROM.

cdromcom - eject CD worked fine.

My problem is solved.
Installing XPE on headless PCs from bootable USB-CD - DOS - Ghost will be much easier now.

Thank you for the tip.
Lasse.
 
Back
Top