similar to: [PATCH] daemon: inspect: better handling windows drive mapping.

I saw several Windows disk images which contains strange registry entry for mapped drives: "\\DosDevices\\Y:"=hex(3):00,00,00,00,00,00,00,00,00,00,00,00 Which is decoded something like diskID = 0x0, partition starts at 0 bytes offset from the start of the disk. In addition to a Windows disk image, I have attached dummy disk and made xfs file system on a whole device without

By creating an empty disk and using it as the first disk of the vm (i.e. /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the iteration order of the disks. This causes inspect_os() to fail since Parted returns a Unix_error if the device does not contain any partitions - fix this by handling this Unix_error. Signed-off-by: Sam Eiderman <sameid@google.com> ---

Yea, I noticed that commit, but since it was used in gpt too regardless of that commit, I decided not to mention this regression. I also noticed that list_filesystems() still works, this is probably due to filtering of devices (daemon/listfs.ml): "let devices = List.filter is_not_partitioned_device devices in" What do you have in mind here? On Tue, Jun 30, 2020 at 12:33 PM Pino

On Tuesday, 30 June 2020 10:33:40 CEST Sam Eiderman wrote: > By creating an empty disk and using it as the first disk of the vm (i.e. > /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the > iteration order of the disks. > This causes inspect_os() to fail since Parted returns a Unix_error if > the device does not contain any partitions - fix this by handling this >

Mostly a line-for-line translation of the C inspection code. --- daemon/Makefile.am | 2 + daemon/inspect_fs.ml | 6 + daemon/inspect_fs_windows.ml | 491 ++++++++++++++++++++++++++++++++++++++++++ daemon/inspect_fs_windows.mli | 24 +++ 4 files changed, 523 insertions(+) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index a4657ed86..80314a524 100644 ---

No need to redeclare them again in few modules, just use them from the Structs module. --- daemon/btrfs.mli | 8 +------- daemon/inspect_fs_windows.ml | 4 ++-- daemon/listfs.ml | 4 ++-- daemon/parted.mli | 9 +-------- daemon/statvfs.mli | 16 +--------------- 5 files changed, 7 insertions(+), 34 deletions(-) diff --git a/daemon/btrfs.mli

No need to redeclare them again in few modules, just use them from the Structs module. --- daemon/btrfs.mli | 8 +------- daemon/inspect_fs_windows.ml | 4 ++-- daemon/listfs.ml | 4 ++-- daemon/parted.mli | 9 +-------- daemon/statvfs.mli | 16 +--------------- 5 files changed, 7 insertions(+), 34 deletions(-) diff --git a/daemon/btrfs.mli

From: "Richard W.M. Jones" <rjones at redhat.com> When a Windows guest doesn't have a HKLM\SYSTEM\MountedDevices node, inspection fails. However inspection should not completely fail just because we cannot get the drive letter mapping from a guest. --- src/inspect_fs_windows.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git

On Fri, Feb 05, 2016 at 12:15:32PM -0500, Dawid Zamirski wrote: > This patch updates the guestfs_inspect_get_drive_mappings API call to > also return drive letters for GPT paritions. Previously this worked > only for MBR partitions. This is achieved by matching the GPT partition > GUID with the info stored in the blob from > HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

pragma GCC diagnostic is a gcc 4.6+ feature, compilation fails with older compilers: inspect-fs-windows.c: In function 'map_registry_disk_blob': inspect-fs-windows.c:502: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:503: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:505: error: #pragma GCC diagnostic not allowed inside

On Fri, 2016-02-05 at 18:08 +0000, Richard W.M. Jones wrote: > On Fri, Feb 05, 2016 at 12:15:32PM -0500, Dawid Zamirski wrote: > > This patch updates the guestfs_inspect_get_drive_mappings API call > > to > > also return drive letters for GPT paritions. Previously this worked > > only for MBR partitions. This is achieved by matching the GPT > > partition > >

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

Hello, I wonder if has seen a problem of the sorts I am describing as at the moment it is driving me nuts. We have an array of LSI disks (Hardware Raid 5) which are attached to a Linux node. The Node has a LSI929 dual fibre channel card that has a channel attached to controller A and B of the array. So we have a list of devices under /proc/partitions mapping what we are expecting to see

I compiled rsync-2.5.5 on HPUX 11.11, using the +DA2.0W and +O3 options. invoking a simple rsync to transfer a file works (I ran a diff on the file, no changes) e.g: sdx1 214: ./rsync --rsh='/usr/bin/ssh -x' --rsync-path=/usr/local/src/rsync-2.5.5/rsync /scratch/chuck/tmp.test sdx2:/scratch/chuck However, adding the -a option yields an unexplained error: (In all of the following cases

Rely on currying, and avoid extra helper functions. No behaviour changes. --- daemon/inspect_fs_unix.ml | 20 ++++++++++---------- daemon/inspect_fs_windows.ml | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/daemon/inspect_fs_unix.ml b/daemon/inspect_fs_unix.ml index 59e26a05e..3ad119306 100644 --- a/daemon/inspect_fs_unix.ml +++ b/daemon/inspect_fs_unix.ml @@ -68,7

This safe wrapper around Unix.openfile ensures that exceptions escaping cannot leave unclosed files. There are only a few places in the code where this wrapper can be used currently. There are other occurences of Unix.openfile but they are not suitable for replacement. --- common/mlstdutils/std_utils.ml | 4 ++++ common/mlstdutils/std_utils.mli | 6 ++++++ daemon/devsparts.ml | 5

This safe wrapper around Unix.openfile ensures that exceptions escaping cannot leave unclosed files. There are only a few places in the code where this wrapper can be used currently. There are other occurences of Unix.openfile but they are not suitable for replacement. --- common/mlstdutils/std_utils.ml | 4 ++++ common/mlstdutils/std_utils.mli | 6 ++++++ daemon/devsparts.ml |

Hi, On Friday, 24 April 2020 14:57:38 CEST Andrew Thurber (anthurbe) wrote: > This multi-disk ovf generates “no href in ovf:File (id=)” > Other single-disk ovfs on the same system work. I don’t have another multi-disk ova to try. > I’ve compared the syntax with the test file on github and it appears to be essentially the same: > virt-v2v/tests/test-v2v-i-ova-two-disks.ovf > Any