FBWF corrupts files during a commit. Possible BUG

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

Guest

Hi,

I have recently built an embedded XP image for a customer that incorporates
the new “File based write filter†to protect a Compact flash drive (Drive C).
Our customer has experienced a problem while writing their software that may
be a bug with the write filter. The problem leads to files becoming corrupt
or more accurately empty during a commit. The problem seems to arise when a
file is read, written, and then committed quickly.

Below is an example batch file that reproduces the problem:

Rem ------------------------------------------------------
Rem Perform a read operation on the file first
copy C:\file1.exe NUL

Rem Then immediately do the copy operation
Copy /Y C:\file2.exe C:\file1.exe

FBWFMGR /commit c: \file1.exe
Rem ------------------------------------------------------

After running this batch file the copied file (file1.exe) is all 0’s at
byte level.

The problem can be avoided by adding a pause between the read and write
operation. An example is below.

Rem ------------------------------------------------------
Rem Perform a read operation on the file first
copy C:\file1.exe NUL

Rem sleep for 1 second
sleep 1

Rem Then immediately do the copy operation
Copy /Y C:\file2.exe C:\file1.exe

FBWFMGR /commit c: \file1.exe
Rem ------------------------------------------------------

Adding the one second pause as above makes the file copy and commit as
expected.

It seems to me that if a file is read and then written to quickly it becomes
corrupt (or empty) at the FBWF overlay layer as if the file is not committed
the file copies as expected. At least until the OS is rebooted and changes
are lost.

Any help with this issue would be much appreciated.
 
Hi David,
This is a timing issue bug. I've opened a bug in our database.
I'll post again when i have more information.

Thank you for bringing this to our attention..
-milong
 
So this problem occurs because we have a handle opened with read only access
and attempt to open the file again with write access.

I'm afraid there isn't a good workaround except the delay you are currently
using.
I'll make sure this makes it in our next release.

thanks
-milong
 
Hi Milong,

Do you have any estimates on when your next release will be? Our customer is
finding this problem frustrating as they have designed their software around
the file based write filter and this problem means they can not use it.

Regards

David Robinson
 
We have just released Feature Perview 2008. We are gathering feedback from
this CTP and will determine the release date as a result of the feedback.

thanks
-milong
 
Back
Top