Dear experts, I am a newbie for minifilter driver development. Recently I am making a minifilter drive whose mission is to manage file backups through hardlink way. I just encounter a problem like this:
Assume file A and file B are hard-linked files [through win32 CreateHardLink()]
Read file B’s property and notice the read-only flag is still SET there
Wait for several seconds/minutes, read file B’s property again, notice the read-only flag is cleared.
I guess this is caused by file system cache and it implies a potential bug in NTFS driver itself because I think it should synchronize file properties of two hard-linked files for us. Now my question is how I can workaround this problem in minifilter driver level? Any kernel API to invalidate file properties cached in file system cache? Something like IoFlush().
Appreciate your attention and help! Thank you in advance.
> 3. Read file B’s property and notice the read-only flag is still SET there
How are you reading the property? The upper layers of the OS (I leam win32
and explorer mostly) are pretty cavalier as to which of the 3 options (that
I can think of) to use (IRP_MJ_QUERY_INFORMATION, Directory lookup,
NetworkQueryInformation Fastio). Often explorer will ask for all three just
for the joy of it (and then lookup desktop.ini…).
I could imagine that if one of the lookups is to the directory then things
could go out of sych until a close happens.
Use Win32 SetFileAttributes() to erase READ-ONLY flag
Close the handle to file A
Use Win32 GetFileAttributes() to query file B’s properties
Also the out-of-sync problem can be reproduced by simply change the file A’s read-only flag in Windows explorer window and then check file B’s property. You can notice that they are not the same until several seconds/mins later.
What is the problem? Yes, visibly that is true ( for several seconds or
minutes ). Just curious about your scenario, where you think it could be a
problem ! Where is the hole you find?
-pro
----- Original Message -----
From: To: “Windows File Systems Devs Interest List” Sent: Wednesday, November 21, 2007 8:43 PM Subject: RE:[ntfsd] File Properties/Length is out-of-sync for two hard-linked files!
> Add-on Info: > > 1. Use Win32 CreateFile() to open file A > 2. Use Win32 SetFileAttributes() to erase READ-ONLY flag > 3. Close the handle to file A > 4. Use Win32 GetFileAttributes() to query file B’s properties > > Also the out-of-sync problem can be reproduced by simply change the file > A’s read-only flag in Windows explorer window and then check file B’s > property. You can notice that they are not the same until several > seconds/mins later. > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@garlic.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Pro, I think you misunderstood me. What I mean is if two files are hard-links, don’t you think would it be nicer for microsoft NTFS driver itself to keep their attributes synchronized? After all, these two file names point to the same physical file. From common sense point of view, can you deny that two hard-linked files should keep only one copy of all the attributes? Or at least, hard link creation code in NTFS driver should do the synchronization on behalf of caller? Or at least, you probably can point out a way on how to invalidate a file attributes cache. I think your previous reply is neither helpful nor constructive.
Actually I was trying to findout if this is a real hole from the programming
point of view or not. For example, there are a host of driver files that are
“known good files” from the OS point of view, but without any tweak, if you
try to replace a file, and look thru cmd line if it replaced or not, you
will see it did. After a small epoch, if you try to look at it again, you
will see now the original file is there… File systems, Memory management,
etc have few lazy policies and it is to have a much better performance
without compromising the correctness.
I will certainly agree that there is a problem if —
Hardlink is already created
Open file A
Change attribute from read-only to read-write using file A handle from
step(2)
Close file A
open file B ( i.e. using hardlink)
Try to write using B or Check for attribute
-pro
----- Original Message -----
From: To: “Windows File Systems Devs Interest List” Sent: Thursday, November 22, 2007 6:12 AM Subject: RE:[ntfsd] File Properties/Length is out-of-sync for two hard-linked files!
> Hi Pro, I think you misunderstood me. What I mean is if two files are > hard-links, don’t you think would it be nicer for microsoft NTFS driver > itself to keep their attributes synchronized? After all, these two file > names point to the same physical file. From common sense point of view, > can you deny that two hard-linked files should keep only one copy of all > the attributes? Or at least, hard link creation code in NTFS driver should > do the synchronization on behalf of caller? Or at least, you probably can > point out a way on how to invalidate a file attributes cache. I think your > previous reply is neither helpful nor constructive. > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@garlic.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Pro, thanks for understand my initial problem. The scenario described in your last reply is exactly what I encountered during minifilter driver development. File A and B are two hard-linked files. I modify an attribute (e.g. read-only flag) on file A through its handle, and open file B to write. System returns error saying the file is ready-only. If I wait several seconds/minutes, and then open file B again to write, everything becomes OK. I felt this might be a bug in current NTFS file system driver, and I am looking for a workaround at minifilter driver level - something like invalidating file B’ cache after file A’s attributes are modified. Any idea?
If you open the same file using hardlink, after you close the handle A ( and
they are both from application level ), then I think you should look at how
you are handling the closing in your minifilter.
I really don’t see there is a need to invalidate cache on handle B. I’m not
very current on these but few things to look at are -
How the set information path works?
Are you intiating caching on these files? If so, what are the things needed
in the closing path?
Still I’m not sure what you mean by invalidating cache of B, if you open B
after you closed A.
-pro
----- Original Message -----
From: To: “Windows File Systems Devs Interest List” Sent: Thursday, November 22, 2007 7:57 AM Subject: RE:[ntfsd] File Properties/Length is out-of-sync for two hard-linked files!
> Hi Pro, thanks for understand my initial problem. The scenario described > in your last reply is exactly what I encountered during minifilter driver > development. File A and B are two hard-linked files. I modify an attribute > (e.g. read-only flag) on file A through its handle, and open file B to > write. System returns error saying the file is ready-only. If I wait > several seconds/minutes, and then open file B again to write, everything > becomes OK. I felt this might be a bug in current NTFS file system driver, > and I am looking for a workaround at minifilter driver level - something > like invalidating file B’ cache after file A’s attributes are modified. > Any idea? > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@garlic.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
Finally I thought that without your minifilter, and using the app level
scenario you can create the problem, since you mentioned that ntfs might
have a bug ( in your one of the first email !).
File system metadata ( of course different stream(s)) can have cached
information, and what I was thinking is that without your minifilter you
could really produce such a hole. That is to say that, you only uses win32
apis as per the docs says, you close the final handle ( so clean up takes
care of necessary flushing !). You open another handle using hardlink. Try
to write, or check on the attributes, and bang!, we still have read-only
attributes.
-pro
----- Original Message -----
From: “Prokash Sinha” To: “Windows File Systems Devs Interest List” Sent: Thursday, November 22, 2007 8:59 AM Subject: Re: RE:[ntfsd] File Properties/Length is out-of-sync for two hard-linked files!
> If you open the same file using hardlink, after you close the handle A ( > and they are both from application level ), then I think you should look > at how you are handling the closing in your minifilter. > > I really don’t see there is a need to invalidate cache on handle B. I’m > not very current on these but few things to look at are - > > How the set information path works? > > Are you intiating caching on these files? If so, what are the things > needed in the closing path? > > Still I’m not sure what you mean by invalidating cache of B, if you open B > after you closed A. > > -pro > > ----- Original Message ----- > From: > To: “Windows File Systems Devs Interest List” > Sent: Thursday, November 22, 2007 7:57 AM > Subject: RE:[ntfsd] File Properties/Length is out-of-sync for two > hard-linked files! > > >> Hi Pro, thanks for understand my initial problem. The scenario described >> in your last reply is exactly what I encountered during minifilter driver >> development. File A and B are two hard-linked files. I modify an >> attribute (e.g. read-only flag) on file A through its handle, and open >> file B to write. System returns error saying the file is ready-only. If I >> wait several seconds/minutes, and then open file B again to write, >> everything becomes OK. I felt this might be a bug in current NTFS file >> system driver, and I am looking for a workaround at minifilter driver >> level - something like invalidating file B’ cache after file A’s >> attributes are modified. Any idea? >> >> — >> NTFSD is sponsored by OSR >> >> For our schedule debugging and file system seminars >> (including our new fs mini-filter seminar) visit: >> http://www.osr.com/seminars >> >> You are currently subscribed to ntfsd as: xxxxx@garlic.com >> To unsubscribe send a blank email to xxxxx@lists.osr.com > > > — > NTFSD is sponsored by OSR > > For our schedule debugging and file system seminars > (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars > > You are currently subscribed to ntfsd as: xxxxx@garlic.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
yes, this is exactly the problem. Even without my minifilter driver, meta data out-of-sync issue is still there. What I want to do is to put some kind of workarounds in my minifilter driver to overcome this problem and hide the details from my own application.
This isn’t a bug - it’s just a relic of some on disk structure choices made
several decades ago, which got crystalized into a network API about the same
time and have turned out to be problematic to many file system developers
since (I speak as one who was first burnt over 15 years ago).
The problem is that for the sake of efficiency in the face of said APIs NTFS
has to keep the attributes and size in the directory entry as well as in the
file…
So if you have a hard link you have the same information in three places.
If you have (n) hard links you will have the inforation in (n+2) places…
Having information in two places is bad enough (when you think about it it
is pretty spectacular that NTFS keeps the two up to date), but things get
out of hand when there are more then 2.
This was what my question about “which mechanism you are using” came from.
If you get the information from the file then you will always be up to date,
if you rely on directory lookup you will have a problem. I’d urge you to
fix the application to do this. Fixing an application in the filesystem is
a really bad idea (but all too common I fear).
If you insist on fixing this with a filter you have two options. Neither of
them are going to be efficient or pretty (which is, no doubt, why NTFS does
this on a delayed basis).
You can sense the set info and then search for all the other entries and
cause them to be updated. I understand that from Vista onwards you can
enumerate all links (I’ve not looked) which might give you the lever you
need. Otherwise you are going to have to search the disk (yea, right)
You can intercept directory lookup and modify the bit as they go by.
This is going to absolutely clobber your directory lookup performance so you
want to avoid doing it as much as you possibly can.
But I’d fix the app - it is making unreasonable assumptions about the API it
is using and it should be using a more trustworth API.
The same issue is with a file size for a huge file under active
writing/growth. The DIR command or Explorer file list will show the smaller
size, while the File/Properties dialog will show the adequate size.
This is NTFS’s issue which results from keeping the size and attributes
both in the dirent and in the MFT. They go out of sync sometimes.
wrote in message news:xxxxx@ntfsd… > Dear experts, I am a newbie for minifilter driver development. Recently I am making a minifilter drive whose mission is to manage file backups through hardlink way. I just encounter a problem like this: > > 1. Assume file A and file B are hard-linked files [through win32 CreateHardLink()] > 2. Modify file A’s property (e.g. remove read-only flag) > 3. Read file B’s property and notice the read-only flag is still SET there > 4. Wait for several seconds/minutes, read file B’s property again, notice the read-only flag is cleared. > > I guess this is caused by file system cache and it implies a potential bug in NTFS driver itself because I think it should synchronize file properties of two hard-linked files for us. Now my question is how I can workaround this problem in minifilter driver level? Any kernel API to invalidate file properties cached in file system cache? Something like IoFlush(). > > Appreciate your attention and help! Thank you in advance. >
Thanks a lot for the information and help. Now I hook “set info” callbacks inside which the attributes of all related all hard-linked files are to be set at one shot. It seems work in my scenario. Need to test the performance impact. BTW, I am wondering whether there is any way in kernel to access NTFS dirent structure?