IIS wrongly reports 'Permission Denied'

Discussion in 'ASP General' started by Richard Shea, Aug 14, 2003.

  1. Richard Shea

    Richard Shea Guest

    Hi - I have an ASP script which does numerous writes via FSO using ...

    Function LogActivity(strText)
    Dim fso, f
    Dim strTime
    strTime = ABCNOW()
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set f = fso_OpenTextFile((ABC_OS_ROOT_PATH & "ABCMAINLOG.txt"), 8,
    f.WriteLine strTime & " " & strText
    End Function

    .... We have recently tripled the number of users using the app have
    found that IIS is intermittently reporting 'Permission Denied' while
    writing to the log. You can try again a moment later and all will be
    well. Has anyone seen this ? It seems very strange that W2K can't deal
    with multiple processes/threads writing to the same file without
    getting itself confused ! To give you an idea of volume the script is
    being invoked up to twice a second at peak times and each invocation
    results in approx 150 calls to the above function. That doesn't seem
    particularly radical to me but ... By the way the incidence of the
    problems seems to be proportional to both the size of the file and the
    density of the script requests.

    There is a post in this newsgroup from a couple of months back ...


    .... which seems to be about the same issue but nothing much in the way
    of a reply.

    Does anyone know of any known issue with W2K/IIS/FSO which might make
    it behave this way ?


    Richard Shea.
    Richard Shea, Aug 14, 2003
    1. Advertisements

  2. Richard Shea

    Alan Guest

    I don't think it's magic - it's just that one process is locking the file
    for the update and another process is trying to get access - the same thing
    happens with databases, source code control systems, the Application object
    (if you use the Lock() method), etc... The longer your files are of course
    the longer it'll take to do each update, and the longer the lock will
    persist. My logger classes normally start a new log each day - this keeps
    file sizes down.

    You need to avoid or handle the error. You could use a loop with On Error
    Resume Next that continues until a valid reference to the TS is returned
    (watch out for infinite loops), or you could arbitrate access by using a
    global semaphore/flag that you store in the Application object. When your
    logger class gets a reference to the TS it sets the flag and clears it on
    release - other instances of your log class enter a wait state (a queue)
    until the flag clears. If you wanted to get really tricky maybe MSMQ would
    hold some ideas.


    Alan, Aug 14, 2003
    1. Advertisements

  3. Richard Shea

    Richard Shea Guest

    Good idea. We hadn't foreseen the volume of logging that would result
    from the system being used in production and this type of approach
    would certainly have helped !
    You've made clear to me that my model of how W2K handles this type of
    file was wrong. I was thinking that by default W2K would allow
    multiple processes to open and write to the file and would arbitrate
    between them. On reflection that was probably a bit hopeful ! Thanks
    for the suggestions above for the moment I'm looking at moving the
    logging to a database table but if that's too slow I'll try out some
    of the above.


    richard shea.
    Richard Shea, Aug 24, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.