Threading and Event (Permissions?) Problem



This is my first time posting here, so i apologize if i'm posting in the
wrong subgroup or whatever, but here goes...

I’m having a problem with threading and events (permissions?) in a
Windows application (background service). I’m trying to write an application
that processes files, launching a new thread for each file that is dropped
into a certain folder. Now, the application works like a charm on my Win2000
machine, but when I moved it to the Win2000 server, where it will eventually
need to run, it fails. One of the processes that are run on the file is a
process to decrypt the file, and this is the only process that won’t work on
the server. Since there is no debugger on the server, I just stripped down
the application, so I could find where the problem is. It turns out that the
decryption process will work on the server if I call the method directly.
But, if I instantiate a child thread to handle the file, and that thread
calls the decryption process, then the application fails. A funny thing is
that if I put a Msgbox in the middle of the decryption process and click the
OK button when it pops up, then the process works fine, even with the
instantiation. Too bad I don’t want the Msgbox. It also fails if i forget
about threading, and put the call to the decryption process in the event
handler for the FolderWatcher.Created in the parent thread, despite it
working fine if i call the process directly from the constructor or Main() of
the parent. And like i said, everything works fine on my machine, it's just
on the server that the failure happens.

Anyway, here’s an edited version of the stripped-down code to illustrate the
threading scenario failure:

Public Module DecryptTestParent
Public Sub Main()
'''''' Version 1: Direct Call - This works fine ''''''
'Dim dtCh As New DecryptTestChild()

'''' Version 2: Instantiation - This doesn't work ''''
Dim dtCh As New DecryptTestChild()
Dim pThread As New System.Threading.Thread( _
New System.Threading.ThreadStart(AddressOf dtCh.DoDecrypt))

' Just to make sure parent doesn't somehow strand child
While pThread.IsAlive : End While
End Sub
End Module

Public Class DecryptTestChild
Public Sub DoDecrypt()
Dim ReturnObject As Object = fctDecryption( _
"..\..\External Objects\Files_Repository\EncryptedFile.sur")

If Not IsError(ReturnObject) Then
Else : MsgBox(ReturnObject.Message.ToString())
End If
End Sub

Public Function fctDecryption(ByVal FileName As String) As Object
' This method has been editted for privacy and simplicity.
' Just know that it eventually calls a 3rd-party decryption
' module in order to decrypt the file.
Return DecryptedStringOrException
End Function
End Class

Now it’s likely that the 3rd-party decryption class creates, accesses, or
deletes temporary files and accesses private information for somewhere, and
it’s failing on the server because it doesn’t have permission to do so. Is
that right? Is there some issue with child threads not having the same
permissions as the parent? Is there something that I can do about that? I
tried setting the parent thread’s CurrentPrincipal to the child’s
CurrentPrincipal, but it didn’t help. Maybe I wasn’t doing it properly,
though. Is there some limitation in terms of permissions with using the
FolderWatcher.Created event?

Oh, and the 3rd-party decryption process doesn't tell me what the error is.
It just returns an empty object, instead of the structure that i'm hoping
for. It sucks, but i'm stuck with using their library, and their stuff works
fine otherwise.

Any help?



Chris Dunaway

hecklar said:
that right? Is there some issue with child threads not having the same
permissions as the parent? Is there something that I can do about that? I

It is my understanding that child threads would have the same
permissions at the parent, but I may be wrong.

You mentioned the FileSystemWatcher.Created event. That event would be
fired when the file is created, but at that point, the file may not be
completely written to disk yet. That might explain why the message box
in the middle of the code seemed to make it work. That slight delay,
might have given it enough time to finish writing the file. You might
try subscribing also the file Changed event and when the event fires,
note the time and when it has gone several seconds without a change,
assume that file is completely written and try to open it then.

Anyway, good luck.





No, it's not the delay. I've tried a million different things to figure out
the problem, but i'm pretty sure it's not a synchronization problem. I added
a pause where the msgbox was and i still get the error. Thus, it shouldn't
be the timing.

I think that by having the msgbox and requiring the user to click the OK
button, it somehow notifies the application which user is running the app.
Like, perhaps, since the System invokes the FileWatcher event, the app thinks
that the System is running the app and oddly doesn't let it do the
decryption, but when i, the Administrator, clicks the msgbox, it suddenly
realizes that it's actually the Administrator and allows it to decrypt. It
sounds ridiculous, especially since the System user has full permissions too,
but that's just what comes to mind.

Someone else mentioned that without the msgbox, the app works as a
background process, so the server doesn't give much priority (authority?) to
the app, but when you put the msgbox in, it suddenly requires user input, so
the server increases the app's priority (authority?), which in turn allows it
to do the decryption. I don't know. That sounds crazy too, but crazy is
where i am at this point.

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. After that, you can post your question and our members will help you out.

Ask a Question