- #Vhd sorry there was a problem mounting the file how to
- #Vhd sorry there was a problem mounting the file code
- #Vhd sorry there was a problem mounting the file windows 8
#Vhd sorry there was a problem mounting the file windows 8
Windows 8 hotfix from 2013, says that it fixes Hyper-V-vhd, ISO-mounting, vhd-backups and vhd-mounting for non-resilient shares. Samba 4.1 SMB 3 from 2014 says that although Samba claims SMB3 protocol support, it lacks the FSCTL_LMR_REQUEST_RESILIENCY feature, that is important for Hyper-V. Microsoft Deploy Hyper-V over SMB doc explicitly mentions SMB 3.0 (but nothing about "Resiliency"). There's a pretty long and misleading history in between Samba and VHD. Thus, I guess that vds.exe is not expecting something like LBA (like fsutil) here, but something like SMB version info and Resiliency support info. On the other hand, there's no QueryRemoteProtocolInformation in the "vhd on OFSMount" trace. Note that it's much shorter and that it ends effectively just after the QueryRemoteProtocolInformation. Here's another Process Monitor trace, captured when trying to mount via Widows Disk Management: vhd on WinFsp - ProcessMonitor.txt (which fails with "The parameter is incorrect"). And the fact that there's no "Share" and "Check for disk errors" options in the disk properties dialog. One simple symptom is the "network drive" disk icon. I'm far from understanding how Windows actually communicates with sshfs-win, but, AFAIU, it treats it more like an SMB share rather than the OSFMount "Logical emulation" disk. Still, looks like it is "real" enough, despite there's no LBA-level access, AFAIU:Ĭ:\WINDOWS\system32>fsutil fsinfo ntfsinfo Y:Ī local NTFS volume is required for this operation.Ĭ:\WINDOWS\system32>fsutil volume querycluster Y: 100500 I'm not sure what OSFMount logical emulation is (and it's free, but not open-source), but the disk it creates is not shown in Windows Disk Management (in contrast to their physical emulation). But on the whole, this looks like some normal file-level I/O and FileSystemControl. Of course, this trace might omit a lot, and there's already one Unknown entry. The event filter was simply filename=Y:\tmp\test.VHD. Here's the associated Process Monitor trace: vhd on OFSMount - Process Monitor.txt. Funny fact: Windows Disk Management is able to mount a ".vhd" image, stored inside an ".img" file, which is stored on a WinFsp-connected share and mounted via OSFMount virtual disk Y: using "Logial" emulation. BTW, it's is able to mount vhd images (read-only, not vhdx), stored on WinFsp-connected storage. I've recently found a nice OSFMount v3.1 (1000) tool. I'm not sure if I correctly understand the "WinFsp file systems are not backed by a real disk" statement, but: #Vhd sorry there was a problem mounting the file code
And if the VHD code insists on disk I/O then there is not anything sensible that we can do in WinFsp to fix the, thanks for the detailed answer. But it would require non-trivial reverse engineering work to determine what needs to be done. Perhaps this is only a matter of responding appropriately to some IOCTL or somehow directing the VHD code to use file system I/O rather than disk I/O.
#Vhd sorry there was a problem mounting the file how to
Given this I am not sure how to fix this in WinFsp. So it not sensible for a WinFsp file system to report the disk device and the block ranges that back a particular file. The problem is that WinFsp file systems are not backed by a real disk (although the user mode file system may use a real disk for storage). It also uses a number of undocumented (at the time?) IOCTL codes for communication. (DISCLAIMER: I do not recall the details and my recollections may be incomplete/incorrect.) It appeared to me that the VHD code bypasses the file system and attempts to access the "disk" underneath it directly.
While working on the ( WinSpd) project, I briefly investigated how Windows handles VHD's.
Here is some speculation based on work I did on a related project. I do not have a good answer for you regarding this problem.
0 kommentar(er)
