Okay, in that case, I’d like to report a bug in the
NulMRx sample.
I’m not sure if I should submit it as part of the filter
manager beta or not, but I figured I’d post about it here
and that way if I’m wrong, perhaps someone can point it
out to me.
So, there are three problems with the NulMRx sample handling
of NulMRxSetFileInformation(), FileEndOfFileInformation case.
- It compares the requested EndOfFile with
capFcb->Header.AllocationSize to determine whether
it should extend or truncate the file.
However, both AllocationSize and FileSize in the fcb
header have already been updated by the wrapper. Thus,
I belive AllocationSize == EndOfFile, and hence always
calls truncate.
I don’t believe this comparison can be done correctly
with the infrastructure in place for NulMRx.
(I would love to see NulMRx be converted into a full
fledge sample that manipulated an in memory file system
for example-- that would be truly useful.)
- The extend case sets the fcb allocation size presumably
because the extend probably had to allocate to the nearest
sector boundary and so didn’t get exactly the requested
space. However, the truncate does not set this.
Both cases need to update the allocation size.
- The trace at the beginning of the case says it is tracing
file size, but actually traces allocation size.
In light of the fact that we can’t determine whether an extend
or truncate is needed without more information, I would suggest
this case be replaced with something like the following comment:
case FileEndOfFileInformation:
RxDbgTrace(0, Dbg, (“FileSize is %d FileSizeHigh is %d\n”,
capFcb->Header.FileSize.LowPart,
capFcb->Header.FileSize.HighPart));
if ( BufferLength < sizeof(FILE_END_OF_FILE_INFORMATION) )
break;
//
// The wrapper has already set capFcb->Header.AllocationSize and
// FileSize to the EndOfFile requested. ValidDataLength has not
// been set.
//
// If the new EndOfFile is past the current (real, not the one in
// fcb which has been updated) allocation size, an extend operation
// should be performed, and capFcb->Header.AllocationSize updated to
// reflect the results of that operation.
[What if the allocation fails? Does the wrapper fix-up the fcb
[if this routine returns failure?
//
// If the new EndOfFile is less than the current read allocation
// size, a truncate operation may need to be preformed. Again,
// AllocationSize should be updated.
//
// ValidDataLength may need to be updated by this routine.
break;
Thanks,
Joseph
Neal Christiansen wrote:
Joseph,
Below are the answers to your questions from the Redirector team:
>A.) Doesn’t this need a lock, or did rdbss already take the
> lock for me?RDBSS will acquire the lock exclusive for you.
>B.) Should I also set FileSize and/or ValidDataLength or
> is rdbss doing this for me as well?For each of the set-information calls, RDBSS will do the default thing.
For example for SetAllocationInfo, RDBSS will set the AllocationInfo on
the FCB before calling into nulmrx. It will also adjust the file size
and the valid data length if necessary.The mini-rdr should in general only bother about performing the required
action on the wire. Of course it has the choice to override the changes
which RDBSS made with its own values. (For example - in SetEndOfFile,
RDBSS will set the filesize and adjust the allocation size to be equal
to the file size. The clever mini-rdr might chose to bump up the
allocation size before returning.>C.) What about in the routines NulMRxExtendFile()
> and NulMRxTruncateFile() ? Do they need to update
> these fields, and do they need a lock to do so?All necessary locks are acquired by RDBSS before it calls the mini-rdr.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Friday, August 27, 2004 8:33 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] NulMrx changing capFcb->Header.AllocationSize w/o a
lock?I’ve started my redirector based on Nul Mrx…
In fileinfo.c, in the NulMRxSetFileInformation() function,
in the processing of FileEndOfFileInformation case,
I see the following code://
// Change the file allocation
//
capFcb->Header.AllocationSize.QuadPart = NewAllocationSize.QuadPart;in the extend case only (this is @ line 482 in the wnet version
from the filter manager beta, but the code is in the previous
versions of the IFS and in the wxp trees as well.)My questions are:
A.) Doesn’t this need a lock, or did rdbss already take the
lock for me?B.) Should I also set FileSize and/or ValidDataLength or
is rdbss doing this for me as well?C.) What about in the routines NulMRxExtendFile()
and NulMRxTruncateFile() ? Do they need to update
these fields, and do they need a lock to do so?I did look at the smb sample as well, but couldn’t find
where it takes locks or updates these field either,
which makes me suspect that I don’t need to do, but
I’m hoping someone with a little more experience can
confirm and say yes, and this is why.On the other hand, I’m not very familiar with the SMB
sample, and it is quite complex to follow, so I may
have missed where it did so.
- Joseph
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
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