TeraByte Unlimited

Greetings! I'm a newbie at your Forum but a long time user of "Image For Windows."

A group of us are "involved" in specialized testing of IFW in a unique system's environment. As a result, questions pop up occasionally. This appears to be the first and second (of many?)...

1. When doing a "Backup Unused Sectors" operation, it appears the idea of using Phylock to lock the FileSYstem has little meaning since the entire disk surface is being imaged, including PhyLock.sys (PhyLock's cache) which is very active during the HOT (or LIVE) imaging operation. Is this really the case or is PhyLock somehow immunizing the "All Sectors" image from active changes in PhyLock.sys?

...and

2. It appears that PhyLock.sys is being established (using normal Windows APIs) prior to entering the PhyLock process via IFWs UpperFilter specifications (we think ). What we're not sure of is whether the contents of the PhyLock.sys cache is merged back into the WIndows FileSystem prior to the release of the PhyLock FileSystem lock or after PhyLock has been abandoned. This knowledge is important to our ongoing investigation.

Any help (users or developers) would be much appreciated... and thanks for letting me use this Forum for these questions!

"Froggie" wrote in message news:[email protected]...

Greetings! I'm a newbie at your Forum but a long time user of "Image For
Windows."

A group of us are "involved" in specialized testing of IFW in a unique
system's environment. As a result, questions pop up occasionally. This
appears to be the first and second (of many?)...


1. When doing a "Backup Unused Sectors" operation, it appears the idea of
using Phylock to lock the FileSYstem has little meaning since the entire
disk surface is being imaged, including PhyLock.sys (PhyLock's cache) which
is very active during the HOT (or LIVE) imaging operation. Is this really
the case or is PhyLock somehow immunizing the "All Sectors" image from
active changes in PhyLock.sys?

>> You don't want to use that to backup the in-use windows partition - there
>> will be too many changes. I believe it would skip the phylock.swp areas
>> but the default is to use RAM mode unless you disable that option.

....and

2. It appears that PhyLock.sys is being established (using normal Windows
APIs) prior to entering the PhyLock process via IFWs UpperFilter
specifications (we think


). What we're not sure of is whether the contents of the PhyLock.sys cache
is merged back into the WIndows FileSystem prior to the release of the
PhyLock FileSystem lock or after PhyLock has been abandoned. This knowledge
is important to our ongoing investigation.


>> Not something you need to worry about. All changes are written to the
>> drive as normal.

Any help (users or developers) would be much appreciated... and thanks for
letting me use this Forum for these questions!

wrote:
>
>
> 2. It appears that PhyLock.sys is being established (using normal Windows
> APIs) prior to entering the PhyLock process via IFWs UpperFilter
> specifications (we think). What we're not sure of is whether the
> contents of the PhyLock.sys cache is merged back into the WIndows
> FileSystem prior to the release of the PhyLock FileSystem lock or after
> PhyLock has been abandoned. This knowledge is important to our ongoing investigation.
>
> Any help (users or developers) would be much appreciated... and thanks
> for letting me use this Forum for these questions!

My understanding of how it works is that, when a block (not yet imaged) is
to be written to the disk by Windows, PHYLock takes a copy of the original
block prior to the write taking place. Then, when that block is being
imaged, the copy stored by PHYLock is written to the image file instead of
what's currently on disk.

This (or a similar scheme) would be needed to guard against corruption in
case of a sudden computer closedown.

(I'm just a user.)

TAC109 wrote:
> wrote:
> >
> >
> > 2. It appears that PhyLock.sys is being established (using normal
> Windows
> > APIs) prior to entering the PhyLock process via IFWs UpperFilter
> > specifications (we think). What we're not sure of is whether the
> > contents of the PhyLock.sys cache is merged back into the WIndows
> > FileSystem prior to the release of the PhyLock FileSystem lock or after
> > PhyLock has been abandoned. This knowledge is important to our ongoing
> investigation.
> >
> > Any help (users or developers) would be much appreciated... and thanks
> > for letting me use this Forum for these questions!
>
> My understanding of how it works is that, when a block (not yet imaged) is
> to be written to the disk by Windows, PHYLock takes a copy of the original
> block prior to the write taking place. Then, when that block is being
> imaged, the copy stored by PHYLock is written to the image file instead of
> what's currently on disk.
>
> This (or a similar scheme) would be needed to guard against corruption in
> case of a sudden computer closedown.
>
> (I'm just a user.)

Hi Tom... we're all just users!

What really happens is after IFW invokes the LOCK, the FileSystem freezes and any data being written to the imaged volume is cached by PhyLock. When the imaging is completed, that cached DATA is released to the System, not the image. The image represents a point in time when it was started (LOCK initialized), not when it was ended. FYI...

On Wed, 29 Apr 2015 12:50:09 PDT, Froggie wrote:

>TAC109 wrote:
>> wrote:
>> >
>> >
>> > 2. It appears that PhyLock.sys is being established (using normal
>> Windows
>> > APIs) prior to entering the PhyLock process via IFWs UpperFilter
>> > specifications (we think). What we're not sure of is whether the
>> > contents of the PhyLock.sys cache is merged back into the WIndows
>> > FileSystem prior to the release of the PhyLock FileSystem lock or after
>> > PhyLock has been abandoned. This knowledge is important to our ongoing
>> investigation.
>> >
>> > Any help (users or developers) would be much appreciated... and thanks
>> > for letting me use this Forum for these questions!
>>
>> My understanding of how it works is that, when a block (not yet imaged) is
>> to be written to the disk by Windows, PHYLock takes a copy of the original
>> block prior to the write taking place. Then, when that block is being
>> imaged, the copy stored by PHYLock is written to the image file instead of
>> what's currently on disk.
>>
>> This (or a similar scheme) would be needed to guard against corruption in
>> case of a sudden computer closedown.
>>
>> (I'm just a user.)
>
>Hi Tom... we're all just users!
>
>What really happens is after IFW invokes the LOCK, the FileSystem freezes and any data being written to the imaged volume is cached by PhyLock. When the imaging is completed, that cached DATA is released to the System, not the image. The image represents a point in time when it was started (LOCK initialized), not when it was ended. FYI...
>
The scenario I outlined above also gives rise to an image at 'a point
in time when it was started (LOCK initialized), not when it was
ended'.

Do you have firm information that *your* theory is correct?

TAC109 wrote:
> On Wed, 29 Apr 2015 12:50:09 PDT, Froggie wrote:
>
> The scenario I outlined above also gives rise to an image at 'a point
> in time when it was started (LOCK initialized), not when it was
> ended'.
>
> Do you have firm information that *your* theory is correct?
Well, if what you say is correct, all my test changes (at the very end of the FileSystem) being made during the HOT "All Sector" image would have wound up in the image... none of them did. They wound up in the Live FileSystem after the completion of the image but not in the image itself, which is actually what I expected.

EDIT: Sorry, Tom... I just re-read your post and indeed your suggested scheme would produce the same result. So, no... I have no firm information on whether my "theory" is correct or not.

On Wed, 29 Apr 2015 16:50:23 PDT, Froggie wrote:

>TAC109 wrote:
>> On Wed, 29 Apr 2015 12:50:09 PDT, Froggie wrote:
>>
>> The scenario I outlined above also gives rise to an image at 'a point
>> in time when it was started (LOCK initialized), not when it was
>> ended'.
>>
>> Do you have firm information that *your* theory is correct?

>Well, if what you say is correct, all my test changes (at the very end of the FileSystem) being made during the HOT "All Sector" image would have wound up in the image... none of them did. They wound up in the Live FileSystem after the completion of the image but not in the image itself, which is actually what I expected.
>
>EDIT: Sorry, Tom... I just re-read your post and indeed your suggested scheme would produce the same result. So, no... I have no firm information on whether my "theory" is correct or not.
>
I suppose one could check the contents of the PHYLock file somehow and
see whether it contains old or new contents of changed blocks.

Or, someone from Terabyte could chip in with a more detailed answer?

All changes are written to the drive real-time as it would be even if
phylock wasn't active.


"Tom Cole" wrote in message news:[email protected]...

On Wed, 29 Apr 2015 16:50:23 PDT, Froggie wrote:

>TAC109 wrote:
>> On Wed, 29 Apr 2015 12:50:09 PDT, Froggie wrote:
>>
>> The scenario I outlined above also gives rise to an image at 'a point
>> in time when it was started (LOCK initialized), not when it was
>> ended'.
>>
>> Do you have firm information that *your* theory is correct?

>Well, if what you say is correct, all my test changes (at the very end of
>the FileSystem) being made during the HOT "All Sector" image would have
>wound up in the image... none of them did. They wound up in the Live
>FileSystem after the completion of the image but not in the image itself,
>which is actually what I expected.
>
>EDIT: Sorry, Tom... I just re-read your post and indeed your suggested
>scheme would produce the same result. So, no... I have no firm information
>on whether my "theory" is correct or not.
>
I suppose one could check the contents of the PHYLock file somehow and
see whether it contains old or new contents of changed blocks.

Or, someone from Terabyte could chip in with a more detailed answer?

TeraByte Support wrote:
> All changes are written to the drive real-time as it would be even if
> phylock wasn't active.

Well, Tom... you be da man!

Thanks for your help with this...