Steve,
Yes, that should work (paging I/O doesn’t extend, which is why Mm
doesn’t worry about this, but everything else DOES extend.)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Goddard
Sent: Wednesday, September 22, 2004 4:21 PM
To: ntfsd redirect
Subject: RE: [ntfsd] File Write Requests
Tony,
One last confirmation question:
If I don’t want to extend the file size, I do the rounded up write
of the last block to the required size for the sector (which increases
file size)and then send a SetFileInformation to set the end of file back
to what
it should be? (The data containing zero’s in-between the correct end of
file and the end of the sector.)
Steve
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, September 22, 2004 12:54 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] File Write Requests
Then the bug is the original caller’s - non-cached I/O needs to be
sector sized. This isn’t a function of the way the file was opened.
From the stack it is probably something ABOVE Norton AV. Try testing on
systems where you have only the symbols for the drivers being debugged -
NAV makes it quite difficult to debug their stuff because they don’t
make symbols (even basic public FPO symbols) available to the rest of us
(now, if I am wrong, someone let me know!)
You can of course manually resume the stack walk above the NAV drivers
(there are articles on OSR Online about doing this, for example). It is
only marginally painful…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class October
18, 2004 in Silicon Valley!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Goddard
Sent: Wednesday, September 22, 2004 3:45 PM
To: ntfsd redirect
Subject: RE: [ntfsd] File Write Requests
Hi Tony et al,
Thanks but that much I realized (forgot to include) but the
original create and the write does not specify parameters
that set IRP_NOCACHE or SL_WRITE_THROUGH in the parameters,
or no intermediate buffering.
The file is opened with GENERIC_READ, GENERIC_WRITE and
the options has FILE_RANDOM_ACCESS. (I am not intentionally
trying to create a non-cached request, just a normal cached write.)
The write request is just built for the resulting file object
and sent down.
It is just that something is triggering the non-cached IO, when
maybe it shoud be calling CcCopyWrite.
The IRP does that the IRP_NOCACHE flag set but my driver did not
set it, the file object has 0x140040 for it’s flags field.
(Random Access, handle created, cache supported).,
Not sure if this would be any real use but
below is the stack from below our driver.
Thanks
Steve
kd> !thread
THREAD 8617a4b8 Cid 03ec.0544 Teb: 7ffac000 Win32Thread: 00000000
RUNNING on processor 0
IRP List:
8601e730: (0006,0094) Flags: 00000030 Mdl: 85ad7358
Not impersonating
DeviceMap e10087c0
Owning Process 86149878
Wait Start TickCount 263336 Elapsed Ticks: 0
Context Switch Count 363
UserTime 00:00:00.0000
KernelTime 00:00:00.0000
Start Address kernel32!BaseThreadStartThunk (0x7c810856)
Win32 Start Address AppMgrService (0x0056ad7f)
Stack Init b1370000 Current b136fc70 Base b1370000 Limit b136d000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr Args to Child
b136f168 806f4966 badb0d00 000001f0 ffffffff nt!KiTrap0E+0x233 (FPO:
[0,0] TrapFrame @ b136f168)
b136f1d8 f7772477 000001f0 f7e7e864 00000400
hal!WRITE_PORT_BUFFER_USHORT+0xe (FPO: [3,0,0])
b136f1fc f7774193 580d4d3f 00000000 85f17484 atapi!IdeReadWrite+0x265
(FPO: [Non-Fpo])
b136f288 f7774bbc 86761370 85f17484 00000000 atapi!IdeSendCommand+0x3ab
(FPO: [Non-Fpo])
b136f2d4 f77770ad 86761370 85f17484 867611c8 atapi!AtapiStartIo+0x23e
(FPO: [Non-Fpo])
b136f300 804dab69 01761030 00000002 86761030
atapi!IdeStartIoSynchronized+0x16f (FPO: [Non-Fpo])
b136f330 f7777fe1 00000000 00000000 00000000
nt!KeSynchronizeExecution+0x17
b136f348 f7778970 86761030 86761030 85f17240
atapi!IdePortAllocateAccessToken+0x1b (FPO: [Non-Fpo])
b136f368 804e4430 86761030 85f17240 867c8e50 atapi!IdePortStartIo+0x1aa
(FPO: [Non-Fpo])
b136f388 f7777c9a 86761030 85f17240 00000000 nt!IoStartPacket+0xa1 (FPO:
[Non-Fpo])
b136f3b4 804e3d77 86761030 00f17240 f77e55fc atapi!IdePortDispatch+0x4e6
(FPO: [Non-Fpo])
b136f3c4 f77e5626 f77e55fc b136f400 f77e5e12 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f3d0 f77e5e12 867d89e8 85f17240 85f172f8
ACPI!ACPIDispatchForwardIrp+0x2a (FPO: [Non-Fpo])
b136f400 804e3d77 867d89e8 f77faf8c 85f173d8 ACPI!ACPIDispatchIrp+0x15a
(FPO: [Non-Fpo])
b136f410 f786f061 f7dd4864 86192008 85f173d8 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f424 f786ed58 85f173d8 867d3b70 86192108
CLASSPNP!SubmitTransferPacket+0x82 (FPO: [Non-Fpo])
b136f454 f786ee49 00000800 00000800 86192008
CLASSPNP!ServiceTransferRequest+0xe4 (FPO: [Non-Fpo])
b136f478 804e3d77 867d3ab8 00000000 867d0130
CLASSPNP!ClassReadWrite+0xff (FPO: [Non-Fpo])
b136f488 f7ab636c 867a92c0 8619212c b136f4c4 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f498 804e3d77 867d7958 86192008 86192150 PartMgr!PmReadWrite+0x93
(FPO: [Non-Fpo])
b136f4a8 f77b01c6 8619216c 867d1818 86192008 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f4c4 804e3d77 867a9208 86192008 86192190
ftdisk!FtDiskReadWrite+0x194 (FPO: [Non-Fpo])
b136f4d4 f784eaa7 86192000 86794100 867d9cf8 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f4e8 804e3d77 8675de38 86192008 86192008 VolSnap!VolSnapWrite+0xbb
(FPO: [Non-Fpo])
b136f4f8 f769d243 86217c10 86192008 b136f6e8 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f508 f769cda6 86217c10 8675dd80 1a9a0000 Ntfs!NtfsSingleAsync+0x6d
(FPO: [Non-Fpo])
b136f6e8 f769dae9 86217c10 86192008 e25b2ab8 Ntfs!NtfsNonCachedIo+0x2f8
(FPO: [Non-Fpo])
b136f8e4 f769dc97 86217c10 86192008 86192008 Ntfs!NtfsCommonWrite+0x1949
(FPO: [Non-Fpo])
b136f948 804e3d77 86794020 86192008 86794bf8 Ntfs!NtfsFsdWrite+0xf3
(FPO: [Non-Fpo])
b136f958 f77403ca 804e91a1 00000000 b136fa14 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
b136f968 804e3d77 867d7020 e485a688 b136f9c0 sr!SrWrite+0xaa (FPO:
[Non-Fpo])
b136f978 b2bc3fd4 00000000 b136f9c0 8671fb60 nt!IopfCallDriver+0x31
(FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be
wrong.
b136fa14 b2af90f2 85b339f0 8664b2b0 f7dd4864
SYMEVENT!SYMEvent_GetVMDataPtr+0x6834
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, September 22, 2004 12:19 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] File Write Requests
Non-cached I/O should be sector sized. That’s a restriction of the API
that NTFS is kind enough to “fix up” for you. YOU should just zero out
the remainder of the sector and send the whole thing down.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class October
18, 2004 in Silicon Valley!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Goddard
Sent: Wednesday, September 22, 2004 3:15 PM
To: ntfsd redirect
Subject: [ntfsd] File Write Requests
Hi there
I am making write requests to a regular file by building the
IRP using IoBuildAsynchronousFsdRequest.
The buffer is pageable memory and the writes are mostly of 4KB blocks.
However, if the write is the last block of a file, length can be an odd
number of bytes, I see that there is a problem if the IO performed by
NTFS
is non-cached. It creates the MDL in the IRP for our required size
but then passes down the IRP to the disk with the size rounded up
to the next whole sector size boundary. Why does it not allocate a
separate
buffer if the new size is greater than the original copy the data and
use that?
The buffer and MDL that is maps it may be contained within the current
page, everything goes by unnoticed, if this additional yardage added to
round up goes into the next page, we can bug check.
Am I missing something, that I should allocate the MDL and with the
round up
size and correct buffer (reallocated) and then pass the original
requested size as the parameter in the stack location?
Am I missing some incorrect setting that causes the NTFS driver to not
assume that it can read beyond the buffer size passed in the stack
location
for the requested write operation?
Are the Create request parameters mismatched for the write request?
Thanks for any help. I am sure I am missing something quite obvious, as
I
can’t imagine this is hit by everyone else otherwise.
Steve
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com