Jump to content











Photo
- - - - -

[AIM Bug] Can't write to recursively mounted container with specific mismatching physical sector sizes

aim arsenal image mounter

Best Answer Olof Lagerkvist , 23 November 2018 - 07:29 PM

This happens because the top-most drive tries to read/write 512 byte aligned data in unbuffered mode. Because the underlying storage requires 4096 byte-aligned I/O for unbuffered requests, this will fail somewhere sooner or later. One way around that is to use for example devio.exe that opens the image file in buffered mode and then have the second AIM call contact the devio instance instead of opening the image file directly.

 

I have had some plans for introducing a command line flag for opening underlying image files in buffered mode that would solve this too. There are a few possibly dangerous side effects with allowing that because going through file system cache with requests *from* disk drivers could lead to dead-locks in file system drivers (file system driver will see this as a request from kernel mode, but still let the request go through the cache system). But it could still be useful of course. But until that is done, devio.exe or similar solutions are your best options!

Go to the full post


  • Please log in to reply
2 replies to this topic

#1 pter6464

pter6464
  • Members
  • 7 posts
  •  
    United States

Posted 23 November 2018 - 07:04 PM

An Arsenal Image Mounter device with 512-byte physical sector size cannot be written to when the backing file exists on an AIM device with 4096-byte physical sector size.
 
Steps to reproduce:
aim_ll -a -t vm -S 4096 -s 512M
Initialize and create an NTFS partition on the newly created AIM device, and assign it a drive letter (i'll assume Z for this example).
fsutil file createnew Z:\Temp 268435456
fsutil file setvaliddata Z:\Temp 268435456
aim_ll -a -f Z:\Temp
Writing anything other than zeroes to the newly created AIM device will fail. Curiously, writing buffers full of zeroes (of any 512-byte-multiple size) will work.
 
The opposite case, an -S 4096 AIM device backed by a file on an -S 512 AIM device exhibits no strange behavior and works normally.
 
I'm using what I believe is the latest AIM driver: DriverVer=05/13/2018,8.5.12.581
 
I appreciate any help with this, and huge thanks for creating and maintaining these awesome tools over the years!

Edited by pter6464, 23 November 2018 - 07:09 PM.


#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 23 November 2018 - 07:29 PM   Best Answer

This happens because the top-most drive tries to read/write 512 byte aligned data in unbuffered mode. Because the underlying storage requires 4096 byte-aligned I/O for unbuffered requests, this will fail somewhere sooner or later. One way around that is to use for example devio.exe that opens the image file in buffered mode and then have the second AIM call contact the devio instance instead of opening the image file directly.

 

I have had some plans for introducing a command line flag for opening underlying image files in buffered mode that would solve this too. There are a few possibly dangerous side effects with allowing that because going through file system cache with requests *from* disk drivers could lead to dead-locks in file system drivers (file system driver will see this as a request from kernel mode, but still let the request go through the cache system). But it could still be useful of course. But until that is done, devio.exe or similar solutions are your best options!


  • pter6464 likes this

#3 pter6464

pter6464
  • Members
  • 7 posts
  •  
    United States

Posted 24 November 2018 - 01:04 AM

Thank you for the fast and detailed reply! Good to know that this is an expected behavior. I'll use devio as a workaround :)

 

I updated my context menus for AIM (which I started in another thread) to support mounting through devio, here they are for those interested:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\AIMMountFile]
@="Mount as &AIM Virtual Disk"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFile\command]
@="C:\\AIM\\aim_lle.bat -a -t file -o rw,fksig -f \"%L\""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFileRO]
@="Mount as &AIM Virtual Disk (read only)"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFileRO\command]
@="C:\\AIM\\aim_lle.bat -a -t file -o ro,fksig -f \"%L\""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFile4K]
@="Mount as &AIM Virtual Disk (4K sectors)"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFile4K\command]
@="C:\\AIM\\aim_lle.bat -a -t file -o rw,fksig -S 4096 -f \"%L\""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFileDIO]
@="Mount as &AIM Virtual Disk (thru devio)"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\*\shell\AIMMountFileDIO\command]
@="C:\\AIM\\aim_dio.bat \"%L\""

[HKEY_CLASSES_ROOT\Drive\shell\AIMUnmount]
@="Unmount &AIM Virtual Disk"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\Drive\shell\AIMUnmount\command]
@="C:\\AIM\\aim_lle.bat -d -m %L"

[HKEY_CLASSES_ROOT\Drive\shell\AIMUnmountF]
@="Unmount &AIM Virtual Disk (force)"
"HasLUAShield"=""

[HKEY_CLASSES_ROOT\Drive\shell\AIMUnmountF\command]
@="C:\\AIM\\aim_lle.bat -R -m %L"

aim_lle.bat (provides elevation, if necessary): 

@echo off
:checkIfElevated
net session 1>NUL 2>NUL
if %ERRORLEVEL% == 0 goto ok
echo Admin privileges required...
%~dp0aim_lle.lnk %*
goto end
:ok
%~dp0aim_ll %*
pause
:end

aim_dio.bat :

@echo off
set dport=9001
:findport
netstat -o -n -a | find "LISTENING" | find ":%dport%" > NUL
if %ERRORLEVEL% == 0 (
  set /a dport += 1
  goto findport
)
start "" /B %~dp0devio %dport% %*
%~dp0aim_lle.bat -a -t proxy -o ip -f localhost:%dport%

aim_lle.lnk is a shortcut to aim_lle.bat with 'Shortcut > Advanced > Run as admin' checked. It is required for elevation.


  • Olof Lagerkvist likes this





Also tagged with one or more of these keywords: aim, arsenal image mounter

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users