FBWF corrupts files during a commit. Possible BUG

> 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
> "David Robinson" <David Robinson@discussions.microsoft.com> wrote in
> message news:3086CF1B-F9CE-4C5A-8C11-470C711AA41B@microsoft.com...

>> 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.

>
>

> 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
>
> "Milong Sabandith [MS]" <milongs@online.microsoft.com> wrote in message
> news:eRRNmFkWHHA.4668@TK2MSFTNGP04.phx.gbl...

> > 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
> > "David Robinson" <David Robinson@discussions.microsoft.com> wrote in
> > message news:3086CF1B-F9CE-4C5A-8C11-470C711AA41B@microsoft.com...

> >> 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 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
>
>
> "Milong Sabandith [MS]" wrote:
>

>> 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
>>
>> "Milong Sabandith [MS]" <milongs@online.microsoft.com> wrote in message
>> news:eRRNmFkWHHA.4668@TK2MSFTNGP04.phx.gbl...

>> > 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
>> > "David Robinson" <David Robinson@discussions.microsoft.com> wrote in
>> > message news:3086CF1B-F9CE-4C5A-8C11-470C711AA41B@microsoft.com...
>> >> 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.
>> >
>> >

>>
>>
>>