A file size may be extended by PAGING_IO under the following conditions:
1 - IRP_MJ_SET_INFORMATION(FileEndOfFileInformation) w/ AdvanceOnly := TRUE.
This is what Tony refers to as the “big enough” request. In other words -
don’t truncate the file!
2 - IRP_MJ_WRITE, IRP_MN_MDL request can extend the file.
/ted
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Tuesday, June 03, 2003 7:16 AM
To: File Systems Developers
Subject: [ntfsd] RE: IRP_MJ_WRITE and paging I/O at EOF
Neil,
An IRP_MJ_SET_INFORMATION request to the file system is a request to CHANGE
the existing file size, not to tell the file system how big the file is.
There is this oddity where the cache manager tells the file system that the
file must be “at least this big” but the file systems (for all intents and
purposes) ignore this request because the file is ALREADY big enough (I
often point to this specific case in file systems class, because
implementing the “logical” thing here leads to erroneous results.) But the
original rationale there is to preserve the VM system guarantees - NO
EXTENDING WRITES.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Tuesday, June 03, 2003 6:50 AM
To: File Systems Developers
Subject: [ntfsd] RE: IRP_MJ_WRITE and paging I/O at EOF
Tony,
Thanks for the reply. I assume you mean it knows the size from
FCB->FileSize?
In that case, what is the purpose of the Set Information? If the FSD
already knows the file size, who is Set Information for?
Thanks again.
Neil
Subject: RE: IRP_MJ_WRITE and paging I/O at EOF
From: Tony Mason
The file system knows the size of the file at all times. When the file is
first opened, it comes from the attributes of the file. The only things
that then cause it to change are:
- A truncation event (overwrite, supersede)
- A set information (ah, but not the one from the cache manager)
- An extending write (which originates from outside the VM system, since the
VM system doesn’t DO extending writes)
Thus, there’s no time when the file system does not know the current size of
the file, although as Nick points out there is no guarantee it will not
change - indeed, this is one reason the Memory Manager locks the file (the
AcquireFile Fast I/O function’s job in life) while using that file size - it
doesn’t want it to change until the file object/section object relationship
has been well established.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com