Yes, setting the EOF to truncate the file is fine.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: xxxxx@yahoo.com
To: “Windows File Systems Devs Interest List”
Sent: 4/9/2017 12:30:41 AM
Subject: RE:[ntfsd] Re[2]: May I write to file but bypass cache manager?
>Thanks Slava,
>>You can modify the request to make it non-cached in a hope that an
>>underlying FSD doesn’t use cache to process non-cached requests.
>
>unfortunately that’s not enough.
>BTW, performing non-cached IO has some alignment Issues as Pete or
>Scott stated before.
>Is setting EOF information enough to correct the file size after a
>non-cached write is performed?
>
>Thanks Jamey,
>I googled a bit. That is finding sector addresses and directly writing
>to disk. This is so much low level that I think synchronization
>problems will occur for sure. is it safe to use this method?
>after writing to disk I should change the file information as well. am
>I right?
>Is this really practical?
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
I feel like we’re very far down a rat hole at this point. You have a
specific behavior that you’re trying to achieve but I really don’t
understand the reasoning. Can you take a step back and describe at a high
level what it is you’re trying to accomplish?
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Thanks for your reply Slava,
I’ve implemented the approach in this post:
http://www.osronline.com/showThread.cfm?link=22397
The file I operate on, is created by my code using fltCreateFile then is
written using cached_IO before calling CcPurgeCacheSection. So I think the
file is not referenced from outside minidirver for mapping
It includes all that locking stated in the referenced post.
The function calls all succeed but still when user mode reads the file it
will be served from the cache.
So you say you do not approve of using this functions in minifilter driver?
Then is there any way that I can refuse cahced_IO in pre read | write and
force the caller to Issue the request as non cached IO? (I do not want to do
it always. It is conditional)
You are right Scott. about the feeling, I mean.
The reason is because I am developing some code for experiment. So there is no specific design or reasoning on why I want to do something in such specific way.
I really appreciate the help I receive from all Pros here. I wish you do not feel bad if I use your help for my experiment and not for a well designed project.
If you are still eager to know that what I am trying to accomplish, then here is the explanation:
I am trying to see if an implementation of a driver providing multiple file view is possible based on using reparse or not.
I create a temp file to provide the second view every time a specific file is being accessed then reparse to it if I want to alter the file view. I the time of pre-read\write, I reference the original content (before reparse) and alter the data.
This question was related to creating the temp file in a way that no data will be cached for it. so I can have altered view cached for the temp file.
I know that my approach may be wrong. And I’ve read about the correct approach here. But since I am new in kernel programming, I like to gain experience and the knowledge by implementing some test code.
If you want different applications to have different views of the “same”
file then you need multiple caching/mm structures. They can’t share a cache
where you evict on demand to pull in the data that you want for the current
application.
Easiest way to handle this is two use separate files on the local volume and
reparse on open as necessary. The underlying FSD will then create unique
caching/mm structures for each file and the data is services appropriately.
If you don’t want to reparse, you need to manage the interactions with the
cache/mm. You can then decide how many views you want and which one to give
to the application at time of open. This is typically referred to as a
“layered file system” because you end up pulling in tons of file system
functionality to make this work. This is a significantly more complex
option.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
You are right Scott. about the feeling, I mean.
The reason is because I am developing some code for experiment. So there is
no specific design or reasoning on why I want to do something in such
specific way.
I really appreciate the help I receive from all Pros here. I wish you do not
feel bad if I use your help for my experiment and not for a well designed
project.
If you are still eager to know that what I am trying to accomplish, then
here is the explanation:
I am trying to see if an implementation of a driver providing multiple file
view is possible based on using reparse or not.
I create a temp file to provide the second view every time a specific file
is being accessed then reparse to it if I want to alter the file view. I the
time of pre-read\write, I reference the original content (before reparse)
and alter the data.
This question was related to creating the temp file in a way that no data
will be cached for it. so I can have altered view cached for the temp file.
I know that my approach may be wrong. And I’ve read about the correct
approach here. But since I am new in kernel programming, I like to gain
experience and the knowledge by implementing some test code.