IIS file handle locks; Q191742 seems extremely non-technical.
Alun Jones
an attempt to improve performance. Q191742 makes note of this, and states
that you can "workaround" this behaviour by disabling memory caching of file
handles, at the penalty of reducing your performance. However, it also
states "Microsoft Notepad and Microsoft Frontpage can overwrite cached files
without error", implying that any other application could be written to
overwrite cached files, if only it were smart enough.
Of course, nowhere in the Microsoft Knowledge Base, or MSDN Library, can I
find out exactly _how_ such an application might be able to "overwrite
cached files without error".
I've asked in several places, without success, as to how this can be
achieved, and I currently use this as one of my best examples of where the
KB is lacking in usable developer information (my other favourite example is
as a Winsock developer, I can't find out exactly _what_ specific bug is
fixed by Service Pack 6a over SP6 - it certainly isn't what's implied by the
rather vague "connecting to a port above 1024").
I'd be most grateful if anyone could give me some details as to exactly how
Notepad and Frontpage get around the caching implemented by IIS - I
sincerely hope it's not through some kind of 'secret' knowledge of the OS
internals, as one person implied to me.
Alun.
~~~~
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613 | us at al...@texis.com. VISA / MC accepted.
Fax +1 (512) 378 3246 | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*
Leo Katona
"Alun Jones" <al...@texis.com> wrote in message
news:87a90l$p011...@news.io.com...
> When IIS opens a file, it leaves that file handle locked for some time, as
> an attempt to improve performance. Q191742 makes note of this, and states
> that you can "workaround" this behaviour by disabling memory caching of file
> handles, at the penalty of reducing your performance. However, it also
> states "Microsoft Notepad and Microsoft Frontpage can overwrite cached files
> without error", implying that any other application could be written to
> overwrite cached files, if only it were smart enough.
>
> Of course, nowhere in the Microsoft Knowledge Base, or MSDN Library, can I
> find out exactly _how_ such an application might be able to "overwrite
> cached files without error".
IIS doesn't actually lock the files. It just keeps them open, but specifically
allows other applications full access to them.
In order to update a "cached" file, your application simply needs to open the
file in a mode that allows IIS to access the file during your update.
The following Win32 API call:
CreateFile("C:\\Inetpub\\supposedlylockedfile.htm", GENERIC_READ |
GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)
will FAIL, since the third parameter (0 = deny other applications all access to
this file while I'm using it) doesn't allow both your application and IIS to use
the file at the same time. In other words, YOU are trying to obtain EXCLUSIVE
access to the file, i.e. lock it. That, by definition, is not possible until all
other applications have closed the file.
However,
CreateFile("C:\\Inetpub\\supposedlylockedfile.htm", GENERIC_READ |
GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL)
will work, because FILE_SHARE_READ allows other applications to open (or keep
open) the file for read access, even though your application may be updating the
file.
You may want to prevent IIS from actually doing any reads during your update. Do
a LockFile(hFile, 0, 0, 0xFFFFFFFF, 0xFFFFFFFF) before starting the update and
an UnlockFile(hFile, 0, 0, 0xFFFFFFFF, 0xFFFFFFFF) when you're finished.
-leok
Alun Jones
<le...@online.tietokone.fi> wrote:
> At 10:24 AM 2/11/2000 , you wrote:
> IIS doesn't actually lock the files. It just keeps them open, but
> specifically
> allows other applications full access to them.
>
> In order to update a "cached" file, your application simply needs to open
> the
> file in a mode that allows IIS to access the file during your update.
>
> The following Win32 API call:
>
> CreateFile("C:\\Inetpub\\supposedlylockedfile.htm", GENERIC_READ |
> GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)
>
> will FAIL, since the third parameter (0 = deny other applications all
> access to
> this file while I'm using it) doesn't allow both your application and IIS
> to use
> the file at the same time. In other words, YOU are trying to obtain
> EXCLUSIVE
> access to the file, i.e. lock it. That, by definition, is not possible
> until all
> other applications have closed the file.
That's not _my_ source code :-). Mine reads:
transfer_localfile=new CFile(transfer_filename,
CFile::modeWrite|CFile::shareDenyWrite|CFile::modeCreate);
That translates to the naked API call:
SECURITY_ATTRIBUTES sa;
sa.nLength=sizeof(sa);
sa.lpSecurityDescriptor=NULL;
sa.bInheritHandle=1;
CreateFile(transfer_filename, GENERIC_WRITE, FILE_SHARE_READ, &sa,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
I'm only denying writes (which the web server portion of IIS shouldn't be
trying to do anyway).
> You may want to prevent IIS from actually doing any reads during your
> update. Do
> a LockFile(hFile, 0, 0, 0xFFFFFFFF, 0xFFFFFFFF) before starting the update
> and
> an UnlockFile(hFile, 0, 0, 0xFFFFFFFF, 0xFFFFFFFF) when you're finished.
It's not an update - it's an up_load_. The existing file is being
overwritten from byte 0 to its end. However, I don't have any problem with
IIS trying to read the file while it's being uploaded.
My main point, however, remains that Microsoft could do with adding extra
developer-only info to a _large_ portion of their knowledge base.