Enhanced Write filter: EwfMgrCommitFile

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am using the Enhanced Write filter (EWF - XP embedded) to protect an NTFS
image on a Compact Flash card (RAM overlay). To update and store a
configuration file I would like to use the EwfMgrCommitFile API. I am
familair with the restrictions: NTFS image should be uncompressed, file
should exist, should have a size > 1 block size and the newly saved file
should have exact the same size. However, when meeting all these restrictions
the EwfMgrCommitFile call still does not persistently store the file. Am I
missing something here?

Thanks in advance for any ideas.
 
I recall there was another "killing" requirement for the EwfMgrCommitFile to work.
Your file's occupied block should not change on the disk (not just file size). Basically the file location must be fixed.
 
That's right. EWF is sensitive to the physical location of the file's data,
not just its entry in the file system tables. The easiest way to ensure the
data doesn't move is to open the file "in-place" and keep a lock on the file
while it's open. If your program just opens the file long enough to read
its data, then later opens it again for writing, you can't guarantee that
the file's data will stay in the same place on the drive. Open the file in
read/write mode and keep it open while the program is running - all the way
up until you know you absolutely won't need it anymore. That should help.
 
The golden bullet.

Thanks, Rob

Matt Kellner (MSFT) said:
That's right. EWF is sensitive to the physical location of the file's data,
not just its entry in the file system tables. The easiest way to ensure the
data doesn't move is to open the file "in-place" and keep a lock on the file
while it's open. If your program just opens the file long enough to read
its data, then later opens it again for writing, you can't guarantee that
the file's data will stay in the same place on the drive. Open the file in
read/write mode and keep it open while the program is running - all the way
up until you know you absolutely won't need it anymore. That should help.

--
-- Matt Kellner
SDET, Microsoft Windows Embedded Team

This message is posted AS-IS, without any warranty, and confers no rights.
Click to expand...
 
The EwfCommitfile is working properly now but keeping the file open while the
program is running is a bit hard to design in. It is an embedded system and
we can lose power so we might not be able to close and commit the file
properly in time.

Does the file stay in place when I open it for read/write, close and commit
it several times in a row? (i.e. each session)

Thanks in advance,
/Rob
 
You don't necessarily have to keep the file open throughout the entire
session. I suggested that as a convenient means of reducing overall file
I/O operations, but alternatively you can simply just open the file as
read/write, stream your data to it, then close it and run the EwfCommitFile
op. The important thing is to make sure the file stays open and locked
while you're using it for I/O - the alternative method (the one you were
originally using) would open specifically for writing, which could cause the
location of the data to change.

You should be able to use the read/write/stream method multiple times. Keep
in mind, however, that each time you write to the file, you are still
consuming space in your EWF overlay - committing the file to disk does not
free the used space in the overlay.
 
Just what I needed - thanks again. I will write a wrapper that provides Read
/ WriteCommit access to our configuration files and hides all the EWF
restrictions.

/Rob
 
Rob,
Have you written this wrapper yet? I am trying to get the
EwfMgrCommitFile API to work and I am unable to do so. If you haven't
written the wrapper, could you at least please post the code that you
were able to get working? Thanks!
Kevin
 
Back
Top