From: SMTP%"dave@silcom.com" 19-SEP-1997 17:56:14.41 To: ntfsd@atria.com CC: Subj: Mm prevents timely CLOSE... and more Return-Path: owner-ntfsd@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Fri, 19 Sep 1997 17:56:06 -0400 Received: by gw.atria.com id Fri, 19 Sep 1997 14:32:40 -0400 Received: from acme.sb.west.net by gw.atria.com id Fri, 19 Sep 1997 14:32:37 -0400 Received: from host5 (host3.miramarsys.com [205.180.87.4]) by acme.sb.west.net (8.8.3/8.6.12) with ESMTP id LAA14098 for ; Fri, 19 Sep 1997 11:32:29 -0700 (PDT) Message-ID: <3422C48B.29AD9378@silcom.com> Date: Fri, 19 Sep 1997 11:29:31 -0700 From: Dave Cox Reply-To: dave@silcom.com X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ntfsd@atria.com Subject: Mm prevents timely CLOSE... and more X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ntfsd@atria.com Precedence: bulk I've developed a network FSD, but am having the following problem: I used to close the network filing protocol's file handle when I got called with IPR_MJ_CLOSE. But, when using some files (like Word docs), I'll get an IRP_MJ_CLEANUP followed by a CREATE with mode and sharing options that are incompatible with the previous open instance of the file, so I'd get a sharing violation. (I saw different behavior for other redirectors: a CLOSE followed the CLEANUP immediately, before the next CREATE -- what can I do to make that happen?) So, I moved the actual network close into the CLEANUP dispatch. This works unless the file is being executed, in which case somebody (memory manager?) continues to read from the file after CLEANUP. So, now I check if there is an ImageSectionObject; if so I delay closing until the CLOSE IRP. The trouble is, I can't execute another copy of the program, or copy it to another location, because the resulting CREATE's open mode (read | write) is incompatible with the sharing mode (share_read | share_delete == "deny write") of the existing open handle. So, how does one handle this? I've considered changing the mode and sharing of the first handle at CLEANUP time. FAT seems to do this (IoRemoveShareAccess), but for me would involve opening a new handle over the network with a new mode, and closing the old handle. Yuck! One other hitch: even when I exit a program, the CLOSE on its file object is not forthcoming. I don't get a CLOSE until the next CREATE has failed. Again, I've observed different behavior by other redirectors. Fortunately, the CREATE always seems to be attempted twice. But I sure wish I knew what I could do to get those CLOSEs to happen sooner. Should I be using MmFlushImageSection at some point? I assume I don't want MmForceSectionObject closed, since it is documented to fail if the file is mapped for the purpose of executing. Well, I'm much obliged for any help all you gurus can offer. Please post to the list, so everyone can learn, comment, and qualify. Thanks! Dave Cox Miramar Systems