I think your method is very dirty - consider a file mapping.
I will try to show you some advanced techniques:
-
From Io-Cc-Mm dependencies the best result is to
do not change any offset in file. Also data in cache
(implemented as section = file mapping) should be
in the open form. Thus if you want to modify the data
on disk you should do this only in non-cached path.
Cached path you don’t want to filter. But file size
considerations you must keep in mind in both
variants. -
From previous => your metadata should be at the end
of file; and I reccomend some alignment (your header
length of 41 bytes is something not good-looking to me)
for both the file stream and your metadata.
Paul
-----P?vodn? zpr?va-----
Od: Rob Linegar [SMTP:xxxxx@des.co.uk]
Odesl?no: Monday, August 21, 2000 1:49 PM
Komu: File Systems Developers
P?edm?t: [ntfsd] Problem skipping a header during reads under Windows
2000.Hi All,
I’ve just encountered a problem with my fs filter which it seems only
occurs
under Windows 2000.
We have a file with a header, currently this header is 41 bytes in size.
The
data after the 41 bytes is a copy of notepad.exe from Windows 98.When we receive an IRP_MJ_READ for the file that has the header we add the
41 bytes offset to nextIrpStack->Parameters.Read.ByteOffset.QuadPart and
set
up
a completion routine.The completion routine copies
currentIrpStack->Parameters.Read.ByteOffset.QuadPart over
currentIrpStack->FileObject->CurrentByteOffset.QuadPart then
checks pIrp->IoStatus.Status. If successful
currentIrpStack->FileObject->CurrentByteOffset.QuadPart is then increased
by
the amount read (pIrp->IoStatus.Information).We are trying to call CreateProcess to run the executable after the
header,
but even copying the file within explorer exhibits this problem.Under Windows NT 4 (sp6) this method “works perfectly” ™(c) etc.
Under Windows 2000 something odd is happening…
At pBuffer[470] (byte 471) into the read data a byte is removed, and at
pBuffer[4054] (byte 4055) a byte is added (byte 4097 in the real file).I changed byte 512 in the file, and the value this is set to does not
match
the value added later on. The byte added is always 0x00.Some interesting observations 471 + 41 = 512, 4055 + 41 = 4096 and 4096 ==
pIrp->IoStatus.Information.Does anyone have any ideas/suggestions?
Rob Linegar
Software Engineer
Data Encryption Systems Limited
You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)