You could have a default timeout in the driver but allow your application to modify it when it decides your driver has something to do. In earlier versions of Windows, it was understandable that not allowing pending returns for creates was the best solution. I remember the days of a mainframe Sperry 1100/60 where the internal executive routine ‘fimain’ was not reentrant. They had been working on making it reentrant for decades, but a safe solution eluded them. The same issues occured in Windows in that the create IRP could cause massive changes in memory with the CacheManager and MemoryManager having to allocate memory for structures and read ahead buffers. All Windows subsystems could not use the file object until it was initialized completely by the FSD since the link to the specific file was not available until the FSD had completed it. With antivirus and antispam filesysem filters, the file may have required extensive reading and analysis before it could be allowed to complete. Also the win32 subsystem did not try and use the file object until it was prepared by the FSD as it had no way to permit an overlapped create. I believe that even with Vista the win32 subsystem won’t allow the calling program’s thread to proceed until the status of the create is available. Another issue to consider is off-line files where a file must be restored from external storage media, usually tape or infrequently optical.
I do suspect that it was a significant modification to the IoManager and FSDs to allow creates to return pending without blocking. During much of the early Windows NT days, the filesystem stack was very undocumented and the IFS Kit ($1000) was not initially released until NT4. Even IoCancelFileOpen was very buggy in early implementations since it could not handle a file object where caching had been initialized during the create request. Of all the things in Windows keeping the filesystem stack stable was a must. I suspect when filesystem filters appeared there were so many variations in how they handled their processing, it inhibited some improvements to the filesystem stack. There may have been some communications issues with other groups at Microsoft dealing with the many various storage stacks from disk.sys, cdrom.sys, flpydisk.sys, and the network redirectors. I once wrote a storage driver that took media with files on it in a foreign format and mapped it into a FAT volume. I do know that when floppy.sys from NT4 was modified into flpydisk.sys and fdc.sys there was little expertise in the storage group for this driver and Microsoft went to outside consultants to get it done. It was done to support floppy controller based tape drives that mostly disappeared shortly (a year or two) thereafter.
“Matt Craighead” wrote in message news:xxxxx@ntfsd…
If the service isn’t running, I just fail the creates. That’s easy. Also, I shouldn’t be getting creates at that point anyway, because it’s the service that is responsible for mapping the FSD to a drive letter.
It’s not clear to me that there is any way to get around returning PENDING on a CREATE. Not only do I have to hand off the request to user space, but I might also have to open a socket, wait for a reply from a server, etc. It’s rather unfortunate that CREATE is the one IRP they chose not to do cancellation on, because CREATE is one of the more likely IRPs to take user-perceptible time in my implementation – sometimes it will be instantaneous, sometimes it might legitimately need to wait for a long time. Not being able to kill processes that are waiting on a CREATE is troubling, while arbitrarily timing out long CREATEs could cause problems, too.
I’ve never liked putting hardcoded timeouts in driver code for precisely this reason: I’m not qualified to make the “what is an acceptable timeout” decision on behalf of the user…
On Tue, Sep 16, 2008 at 7:00 PM, David Craig wrote:
You may find that if you return pending, some filters may not be able to handle that on creates. I hope most are fixed now, but I think I remember having some problems with that in earlier OS versions.
I would say that for most cases anything over a few seconds would be excessive but definitely any wait measured in minutes would cause problems. I also assume you can handle creates while the system is booting so you won’t have to wait for the user subsystem to become available.
“Matt Craighead” wrote in message news:xxxxx@ntfsd…
My apologies, I hit send too early. That should have been:
2. If I do want to support cancellation of CREATE requests on earlier, non-Vista OS’s, I suppose I have to use a KTIMER and implement my own timeouts on creates? Of course this begs the question of how long a timeout I should pick…
On Tue, Sep 16, 2008 at 5:13 PM, Matt Craighead wrote:
My file system driver hands off requests, including IRP_MJ_CREATE, to a user space process and marks them pending. I support cancellation on these requests, but it would appear that Windows XP simply doesn’t bother trying to cancel them. This was fairly confusing until I finally stumbled on some references talking about how Vista added support for IRP_MJ_CREATE cancellation: http://www.microsoft.com/whdc/driver/kernel/iocancel.mspx
Questions:
1. Is there a particular reason why IRP_MJ_CREATE cancellation functions aren’t called on earlier OSs? Is there any more detailed explanation of what exactly was changed here in Vista?
2. If I do want to support cancellation of CREATE requests on earlier OS’s, I suppose I have to use
–
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834
–
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834
—
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834