The software driver must set inuse field in Parallels header to
0x746F6E59 when the image is opened in read-write mode. The presence of
this magic in the header on open forces image consistency check.
There is an unfortunate trick here. We can not check for inuse in
parallels_check as this will ha
The software driver must set inuse field in Parallels header to
0x746F6E59 when the image is opened in read-write mode. The presence of
this magic in the header on open forces image consistency check.
There is an unfortunate trick here. We can not check for inuse in
parallels_check as this will ha
On Wed, Mar 11, 2015 at 01:28:13PM +0300, Denis V. Lunev wrote:
> The software driver must set inuse field in Parallels header to
> 0x746F6E59 when the image is opened in read-write mode. The presence of
> this magic in the header on open forces image consistency check.
>
> There is an unfortunate
On Tue, Mar 10, 2015 at 11:51:13AM +0300, Denis V. Lunev wrote:
> The software driver must set inuse field in Parallels header to
> 0x746F6E59 when the image is opened in read-write mode. The presence of
> this magic in the header on open forces image consistency check.
>
> There is an unfortunate
On Tue, Mar 10, 2015 at 05:44:19PM +0300, Denis V. Lunev wrote:
> On 10/03/15 17:38, Roman Kagan wrote:
> >On Tue, Mar 10, 2015 at 11:51:13AM +0300, Denis V. Lunev wrote:
> >>The software driver must set inuse field in Parallels header to
> >>0x746F6E59 when the image is opened in read-write mode.
On 10/03/15 17:38, Roman Kagan wrote:
On Tue, Mar 10, 2015 at 11:51:13AM +0300, Denis V. Lunev wrote:
The software driver must set inuse field in Parallels header to
0x746F6E59 when the image is opened in read-write mode. The presence of
this magic in the header on open forces image consistency
