Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 9 April 2018

Writing WDF Drivers I: Core Concepts, Manchester, NH, 7 May 2018

Kernel Debugging & Crash Analysis for Windows, Manchester, NH, 21 May 2018


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 4  
30 Dec 17 23:10
Jorgen Lundman
xxxxxx@lundman.net
Join Date: 09 Nov 2017
Posts To This List: 9
Filename in directory listing..

I was hoping I could get some fresh eyes on this issue I am having. I am using "ifstest.exe" to check if my implementation is "correct" and I get this peculiar issue: IRP_MJ_DIRECTORY_CONTROL, IRP_MN_QUERY_DIRECTORY type 1 struct FILE_INFORMATION_CLASS size is 72 single: 1 restart: 0 index: 0 zfs_readdir: 'hfhtest.dat' -> 'hfhtest.dat' (namelen 22) outsize adjusted to 92 -zfs_readdir: num 1 return information size 92 So it asked for a single dirlist, and I returned "hfhtest.dat" length bytes 22 (wide characters 11). Dumping the binary returned: 39 25 FE 12 FileIndex 0-3 49 8D 24 51 E3 7E D3 01 CreationTime 4-11 49 8D 24 51 E3 7E D3 01 LastAccessTime 12-19 49 8D 24 51 E3 7E D3 01 LastWriteTime 20-27 49 8D 24 51 E3 7E D3 01 ChangeTime 28-35 00 00 00 00 00 00 00 00 EndOfFile 36-43 00 00 00 00 00 00 00 00 AllocationSize 44-51 80 00 00 00 FileAttributes 52-55 16 00 00 00 FileNameLength 56-59 68 00 66 00 68 00 74 00 65 00 "hfhte" 60-69 73 00 74 00 2E 00 64 00 61 00 "st.da" 70-79 74 00 74 00 fe 00 12 00 "tt" 80-87 returned string length: 0x16 = 22 struct is 72, with one wide char included. We return size 92. Bytes added up inside struct, and struct size do not match, but most likely about alignment, so we can most likely ignore that. Then the next query from ifstest.exe is: fsDispatcher: enter: major 0: minor 0: IRP_MJ_CREATE fsDeviceObject IRP_MJ_CREATE: FileObject FFFFCE8963B4C460 name '\opcreatg\hfhtest.datt??' flags 0x0 What? Why? I return exactly 22 bytes in Filename. Yes, there is garbage after the string, due to alignment to next 8 bytes. What is the issue here, do strings returned in singles have to be (wide) null terminated? Nothing about that in the docs, surely the filenamelength is the full string, and not minus the 2 chars inside the struct? Lund
  Message 2 of 4  
02 Jan 18 15:56
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 982
List Moderator
Filename in directory listing..

How are you printing the string in the IRP_MJ_CREATE path? -scott OSR @OSRDrivers
  Message 3 of 4  
03 Jan 18 23:49
Craig Barkhouse
xxxxxx@microsoft.com
Join Date: 08 Feb 2012
Posts To This List: 13
Filename in directory listing..

Hi Lund, (1) There should not be any alignment padding after the last entry being returned. In your example only 90 bytes should be returned. This is computed as FIELD_OFFSET( FILE_FULL_DIR_INFORMATION, FileName[0] ) + FileNameLen * sizeof(WCHAR) == 68 + 22 == 90. Of course use the struct corresponding to the info class being queried; it's not always FILE_FULL_DIR_INFORMATION. (2) Between entries, there should be alignment padding inserted so that the next entry starts at a quadword (i.e. 8-byte) boundary. (3) You do not have to null terminate the file name strings. Hope this helps, Craig (MSFT) -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jorgen Lundman <xxxxx@lundman.net> Sent: Saturday, December 30, 2017 8:09 PM To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> Subject: [ntfsd] Filename in directory listing.. I was hoping I could get some fresh eyes on this issue I am having. I am using "ifstest.exe" to check if my implementation is "correct" and I get this peculiar issue: IRP_MJ_DIRECTORY_CONTROL, IRP_MN_QUERY_DIRECTORY type 1 struct FILE_INFORMATION_CLASS size is 72 single: 1 restart: 0 index: 0 zfs_readdir: 'hfhtest.dat' -> 'hfhtest.dat' (namelen 22) outsize adjusted to 92 -zfs_readdir: num 1 return information size 92 So it asked for a single dirlist, and I returned "hfhtest.dat" length bytes 22 (wide characters 11). Dumping the binary returned: 39 25 FE 12 FileIndex 0-3 49 8D 24 51 E3 7E D3 01 CreationTime 4-11 49 8D 24 51 E3 7E D3 01 LastAccessTime 12-19 49 8D 24 51 E3 7E D3 01 LastWriteTime 20-27 49 8D 24 51 E3 7E D3 01 ChangeTime 28-35 00 00 00 00 00 00 00 00 EndOfFile 36-43 00 00 00 00 00 00 00 00 AllocationSize 44-51 80 00 00 00 FileAttributes 52-55 16 00 00 00 FileNameLength 56-59 68 00 66 00 68 00 74 00 65 00 "hfhte" 60-69 73 00 74 00 2E 00 64 00 61 00 "st.da" 70-79 74 00 74 00 fe 00 12 00 "tt" 80-87 returned string length: 0x16 = 22 struct is 72, with one wide char included. We return size 92. Bytes added up inside struct, and struct size do not match, but most likely about alignment, so we can most likely ignore that. Then the next query from ifstest.exe is: fsDispatcher: enter: major 0: minor 0: IRP_MJ_CREATE fsDeviceObject IRP_MJ_CREATE: FileObject FFFFCE8963B4C460 name '\opcreatg\hfhtest.datt??' flags 0x0 What? Why? I return exactly 22 bytes in Filename. Yes, there is garbage after the string, due to alignment to next 8 bytes. What is the issue here, do strings returned in singles have to be (wide) null terminated? Nothing about that in the docs, surely the filenamelength is the full string, and not minus the 2 chars inside the struct? Lund --- NTFSD is sponsored by OSR MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osr.com%2Fse minars&data=02%7C01%7Ccraigba%40microsoft.com%7Ccb16a9e3af134121c21b08d5500441cf% 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636502901795797335&sdata=nkiXsCZbtaz bWrsMY78yC2Yr311oT6KSi4zBCxdWooQ%3D&reserved=0> To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.co m%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7Ccraigba%40microsoft.com%7Ccb16a9e 3af134121c21b08d5500441cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365029017 95797335&sdata=D2mgWvXBHcCUsEY10NYMFOjzJ0IDdB6Oc1t1hVcpNmc%3D&reserved=0>
  Message 4 of 4  
04 Jan 18 00:49
Jorgen Lundman
xxxxxx@lundman.net
Join Date: 09 Nov 2017
Posts To This List: 9
Filename in directory listing..

Hi, Thanks for your replies Craig and Scott. Craig Barkhouse <xxxxx@microsoft.com> wrote: > (1) There should not be any alignment padding after the last entry being returned. In your example only 90 bytes should be returned. This is computed as FIELD_OFFSET( FILE_FULL_DIR_INFORMATION, FileName[0] ) + FileNameLen * sizeof(WCHAR) == 68 + 22 == 90. Of course use the struct corresponding to the info class being queried; it's not always FILE_FULL_DIR_INFORMATION. I had clearly picked up poor coding practices already, as I used sizeof(FILE_DIRECTORY_INFORMATION) - sizeof(eodp->FileName) to work out the size "to advance by", but replacing it with FIELD_OFFSET() made everything happier. These lines are interesting: FILE_DIRECTORY_INFORMATION *eodp; dprintf("type 1 struct size is %d and field_offset size %d size of Name[0] %d\n", sizeof(FILE_DIRECTORY_INFORMATION), FIELD_OFFSET(FILE_DIRECTORY_INFORMATION, FileName[0]); sizeof(eodp->FileName)); type 1 struct size is 72 and field_offset size 64 size of Name[0] 2 So 72 - 2 is 70, some 6 bytes off. Probably the final 2-bytes in FileName is aligned up to 8, but I will only use FIELD_OFFSET() from now on. But it is a little alarming that "they" would use the returned-size in "IoStatus.Information" instead of the FileNameLength. But since it is "ifstest.exe" we'll let it slide, as it proved a point/bug here. zfs_readdir: 'hfhtest.dat' -> 'hfhtest.dat' (namelen 22 bytes: structsize 64) outsize adjusted to 86 -zfs_readdir: num 1 dirlist information size 86 00 00 00 00 D8 15 36 12 52 41 BD 53 E3 7E D3 01 52 41 BD 53 E3 7E D3 01 52 41 BD 53 E3 7E D3 01 52 41 BD 53 E3 7E D3 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 16 00 00 00 68 00 66 00 68 00 74 00 65 00 73 00 74 00 2E 00 64 00 61 00 74 00 IRP_MJ_CREATE: FileObject FFFFCE8963000510 name '\opcreatg\hfhtest.dat' flags 0x0 The best surprise so far was IRP_MJ_CREATE on an existing/new directory, with DeleteOnClose set. I did expect that one. I look forward to finding other surprises as I dig deeper. Lund -- Jorgen Lundman | <xxxxx@lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 06:12.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license