Guy Albertelli galberte@neo.rr.com writes:
1/10 server: Implement FILE_NO_INTERMEDIATE_BUFFERING with O_DIRECT 2/10 kernel32/tests: First test for CreateFile on NT unique volume name 3/10 ntdll: Implement conversion of NT unique volume name to unix file name 4/10 ntdll: Implement internal aligned buffer for I/O with special devices 5/10 kernel32: Make GetVolumeNameForVolumeMountPoint[AW] generate correct name 6/10 kernel32: Implement stub for DeleteVolumeMountPoint[AW] saying we completed it. 7/10 kernel32/tests: Add test for unique volume names to QueryDosDevice 8/10 kernel32: Implement support in QueryDosDevice for unique volume names 9/10 server: Fix error when opening directory r/o with O_DIRECT 10/10 kernel32/tests: More tests of CreateFile on unique volume id
All that stuff should be done in mountmgr, not in ntdll/kernel32.
On Tue, 2009-03-24 at 11:32 +0100, Alexandre Julliard wrote:
Guy Albertelli galberte@neo.rr.com writes:
1/10 server: Implement FILE_NO_INTERMEDIATE_BUFFERING with O_DIRECT 2/10 kernel32/tests: First test for CreateFile on NT unique volume name 3/10 ntdll: Implement conversion of NT unique volume name to unix file name 4/10 ntdll: Implement internal aligned buffer for I/O with special devices 5/10 kernel32: Make GetVolumeNameForVolumeMountPoint[AW] generate correct name 6/10 kernel32: Implement stub for DeleteVolumeMountPoint[AW] saying we completed it. 7/10 kernel32/tests: Add test for unique volume names to QueryDosDevice 8/10 kernel32: Implement support in QueryDosDevice for unique volume names 9/10 server: Fix error when opening directory r/o with O_DIRECT 10/10 kernel32/tests: More tests of CreateFile on unique volume id
All that stuff should be done in mountmgr, not in ntdll/kernel32.
All of the fixes deal with opening and reading/writing *already* mounted devices. None of the fixes deal with mounting/unmounting devices.
I don't understand which part you see fitting in mountmgr.
The actual program 'photoviewer.exe' worked well under Wine until the following code: 0009:Call KERNEL32.FindNextVolumeA(0014de18,008c0c62,00000200) ret=003c17dc 0009:Ret KERNEL32.FindNextVolumeA() retval=00000001 ret=003c17dc 0009:Call KERNEL32.CreateFileA(008c0c62 "\\?\Volume{00000000-0000-0000-0000-00000000005a}",c0000000,00000003,00000000,00000003,20000080,00000000) ret=003c16dc 0009:Ret KERNEL32.CreateFileA() retval=0000006c ret=003c16dc 0009:Call KERNEL32.SetFilePointer(0000006c,00000000,00000000,00000000) ret=003c16f6 0009:Ret KERNEL32.SetFilePointer() retval=ffffffff ret=003c16f6 0009:Call KERNEL32.ReadFile(0000006c,008c0e62,00000200,0033fa8c,00000000) ret=003c1712 0009:Ret KERNEL32.ReadFile() retval=00000000 ret=003c1712 0009:Call KERNEL32.CloseHandle(0000006c) ret=003c173d 0009:Ret KERNEL32.CloseHandle() retval=00000001 ret=003c173d
Drive Z (0x5a above) was manually associated with /dev/sdh with the correct permissions set.
1. The initial problem was that the CreateFile above would not successfully translate the volume id to the associated Unix file. #3/10 fixed that.
2. The FILE_NO_INTERMEDIATE_BUFFER flag seemed to require the O_DIRECT flag during the Unix open. This was proven by having standard Linux code access the device. #1/10 and #9/10 fixed this.
3. Linux requires the I/O buffer for special files (/dev/..) to be aligned on 512 byte boundary to get the correct data. #4/10 corrects that problem for both reading and writing.
4. The photoviewer.exe program later on uses GetVolumeNameForVolumeMountPoint and the DeleteVolumeMountPoint. #5/10 fixes a mismatch between GetVolumeName... and the mountmgr code, and #6/10 implements a stub for DeleteVolumeMountPoint
5. The QueryDosDevice fix (#8/10) came from one of the test programs I using.
Guy Albertelli galberte@neo.rr.com writes:
- The initial problem was that the CreateFile above would not
successfully translate the volume id to the associated Unix file. #3/10 fixed that.
That should go in mountmgr, it already creates the volume symlinks and manages the devices. What is needed is a way to associate a symlink with a real Unix file so that you can do reads/writes on it, not just ioctls.
- The FILE_NO_INTERMEDIATE_BUFFER flag seemed to require the O_DIRECT
flag during the Unix open. This was proven by having standard Linux code access the device. #1/10 and #9/10 fixed this.
I don't see why you'd need O_DIRECT.
- Linux requires the I/O buffer for special files (/dev/..) to be
aligned on 512 byte boundary to get the correct data. #4/10 corrects that problem for both reading and writing.
That's really ugly.
Am Donnerstag, den 26.03.2009, 10:08 +0100 schrieb Alexandre Julliard:
- The FILE_NO_INTERMEDIATE_BUFFER flag seemed to require the O_DIRECT
flag during the Unix open. This was proven by having standard Linux code access the device. #1/10 and #9/10 fixed this.
I don't see why you'd need O_DIRECT.
O_DIRECT avoids buffering in the Linux kernel. If that dumb device makes "block-mapped I/O", i.e. uses read/write requests to perform *actions* on that device, buffering renders the communication unusable.
- Linux requires the I/O buffer for special files (/dev/..) to be
aligned on 512 byte boundary to get the correct data. #4/10 corrects that problem for both reading and writing.
That's really ugly.
That's only the case if the device has been opened with O_DIRECT. For buffered read/write, no alignment is needed.
Regards, Michael Karcher
On Thu, 2009-03-26 at 10:08 +0100, Alexandre Julliard wrote:
Guy Albertelli galberte@neo.rr.com writes:
- The initial problem was that the CreateFile above would not
successfully translate the volume id to the associated Unix file. #3/10 fixed that.
That should go in mountmgr, it already creates the volume symlinks and manages the devices. What is needed is a way to associate a symlink with a real Unix file so that you can do reads/writes on it, not just ioctls.
I now understand what you mean. Like the "dosdevices/c:" symlink, mountmgr should create "dosdevices/volume{00000000-0000-0000-0000-000000000043}" as a symlink to the same place as the c: one.
I will rework this with additional tests.
Guy Albertelli galberte@neo.rr.com writes:
On Thu, 2009-03-26 at 10:08 +0100, Alexandre Julliard wrote:
Guy Albertelli galberte@neo.rr.com writes:
- The initial problem was that the CreateFile above would not
successfully translate the volume id to the associated Unix file. #3/10 fixed that.
That should go in mountmgr, it already creates the volume symlinks and manages the devices. What is needed is a way to associate a symlink with a real Unix file so that you can do reads/writes on it, not just ioctls.
I now understand what you mean. Like the "dosdevices/c:" symlink, mountmgr should create "dosdevices/volume{00000000-0000-0000-0000-000000000043}" as a symlink to the same place as the c: one.
No, that's not what I mean. The symlink is a Windows-style symlink, not a Unix one, and it's created by mountmgr already. It points to something like \Device\Harddisk1; what you need is to make it possible to do reads/writes on that device.
-
Alexandre Julliard -
Guy Albertelli -
Michael Karcher