EWF Commit Question: What if file is corrupted in the overlay?

  • Thread starter Thread starter Kevin W
  • Start date Start date
K

Kevin W

First I would like to thank everyone for making this NG a great
resource. Currently I am having trouble to find the answers to my
following questions. My Target machine is a Touchscreen PC that would
never be properly shut down.

1. Do I need to call EwfMgrCommit after each modifications to Status.xx
for EWF to COMMIT the final changes on the next restart? Or one call
to DoEwfCommit is enough?

2. What if Status.xx file got corrupted while writing to the overlay?
Would EWF discard the DoEwfCommit command on next restart since file
been corrupted? Would EFW delete the corrupted file from the overlay
automatically?

3. Any avaliable tools or codes to simulate field environment? For
example, constant read/write to disk and force shut down in the middle
of write operation?

Any help is much appreciated. I am a Software Intern and still a
novice to the tools avaliable. Any help is much appreciated.
 
Sorry for not making it clear. Status.xx is my personal data file for
my application. It can be modified 100+ times per minute during peak
time. Size ~200k and pretty much the only file that is being modified
and critical to the application.
 
Hi Kevin. I'll try to answer your questions here.

1. In a single Windows session, you only need to call DoEwfCommit once -
this sets a flag that tells the EWF driver to commit the overlay at
shutdown. This will commit whatever is in the overlay at the time the
system shuts down.

2. EWF does not do any validation on the data in the overlay, so if a file
is corrupted in the overlay and you commit it, it will become corrupted on
the protected partition as well. You will need to determine if the file is
corrupt via another method.

3. I'm not aware of any such tools off the top of my head, but others in
this newsgroup may be able to point you to some stress tools that can help
you test your environment.

For more information on power-loss and force-shutdown scenarios and their
effect on EWF Disk Overlays, check out my blog post on this subject here:
http://blogs.msdn.com/embedded/archive/2005/06/15/429225.aspx

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Hello Matt:

Excellent blog! It clarifies a lot of my questions and definitely saved
me a lot of time. One more question if anyone knows the answer:

If XP chkdsk detected a corrupted file, does it delete it? I know for
sure that NT chkdsk delete corrupted files, but what about XP?

Thanks again Matt. BTW, anyone can point me to a stress tool to create
disk corruption?
 
No problem, Kevin. =)

CHKDSK will do one of several different actions on the file, depending on
the nature of the corruption. If the file is "lost" (common problem in FAT
when data is partially written but the FAT table isn't updated), CHKDSK will
create a file entry for that data usually called FILEXXXX.CHK and place it
in either the C: root or a specially named folder for lost clusters. NTFS
has a similar mechanism for lost data.

If the file entry exists but does not match the actual data, the data is
truncated. If this affects binary data, this usually means that the data in
the file is invalid and unusable.

File entries can also be deleted if that's what CHKDSK determines is the
best resolution. Also, file entries can be truncated, moved or deleted in
the case of cross-linked files. There are all sorts of types of data
corruption, so it's really not very easy to tell what will happen.

A more general rule of thumb, though, is that if CHKDSK finds a corrupted
file and does anything with it, you can usually (but not always) count on
the file no longer being usable. This would be the case with or without
EWF, though with an EWF Disk Overlay, you at least have the option of
discarding the overlay and reverting to your original file.

Hope this helps. =)

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
I should probably add that CHKDSK's main purpose is to validate the file
system, not the data itself. CHKDSK for the most part has no way of telling
if a particular file contains the data it's supposed to - it just makes sure
that the file system is clean, all files are where they're supposed to be,
and that any spurious data on the partition is accounted for. CHKDSK could
completely miss a corrupted file because the file is "okay" as far as the FS
is concerned, but the file would still be invalid due to internal data
corruption.

--
Matt Kellner ([email protected])
STE, Windows Embedded Group

This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
 
Back
Top