On Nov 28 22:59, Christian Franke wrote: > There a very few but occasionally interesting use cases for read access to > block devices below /proc/sys: > > - Read raw images behind drive letters which are not linked to regular > /dev/sdXN partitions. For example read decrypted images of VeraCrypt > partitions or container files: > /proc/sys/DosDevices/X: -> /proc/sys/Device/VeraCryptVolumeX > > - Read raw images of Volume Shadow Copies: > /proc/sys/Device/HarddiskVolumeShadowCopy* > > Copying such an image actually works with 'dd', but 'ddrescue' reports a non > seekable device. This is because fhandler_virtual::lseek() is used. It calls > fhandler_procsys::fill_filebuf() which does not make any sense in this > context. This lseek() always fails - without setting errno, BTW. > > The attached experimental patch does not fix the lseek() (sorry), but > handles such block devices with fhandler_dev_floppy instead. Tested with > above use cases. > > I'm not sure whether this could break access to other /proc/sys block > devices. This would happen if fh->exists() returns virt_blk for devices > which do not support IOCTL_DISK_GET_DRIVE_GEOMETRY* or > IOCTL_DISK_GET_PARTITION_INFO*.
Pushed, becasue it's a nice idea. The above problem shouldn't happen, in theory, but I'm not sure. virt_blk is generated for devices types FILE_DEVICE_DISK FILE_DEVICE_CD_ROM FILE_DEVICE_VIRTUAL_DISK FILE_DEVICE_DFS FILE_DEVICE_NETWORK_FILE_SYSTEM FILE_DEVICE_DFS or FILE_DEVICE_NETWORK_FILE_SYSTEM might be a problem, but there should be a way to workaround that, if necessary, isn't it? Maybe it's a bad idea to treat those as blk devices at all? Thanks, Corinna
