>>>>>Hi
>>>>>
>>>>>I'm creating a console app to pgp decrypt some files.
>>>>>
>>>>>This works but when I try and rename the second (and last) file that is decrypted I get an error file in use message.
>>>>>
>>>>>This is the code before I try and rename the file
>>>>>
>>>>>

>>>>>if (fileexists)
>>>>>            {
>>>>>
>>>>>                PGPDecrypt CES_ConCurDecrypt = new PGPDecrypt(CES_PGPEncryptedFile,
>>>>>                                                 @PGPPrivateKeyFile,
>>>>>                                                 PGPPassword,
>>>>>                                                 @PGPOutPutPath,
>>>>>                                                 @PGPPublicKeyFile);
>>>>>
>>>>>                FileStream CES_fs = File.Open(CES_PGPEncryptedFile, FileMode.Open);
>>>>>
>>>>>                CES_ConCurDecrypt.decrypt(CES_fs, @PGPOutPutPath);
>>>>>
>>>>>                CES_fs.Close();
>>>>>
>>>>>            }
>>>>>

>>>>>
>>>>>How can I tell what has the output file still open .
>>>>>
>>>>>Thanks
>>>>>
>>>>>Update
>>>>>
>>>>> I solved my problem by add a stream.dispose() in the decryption routine but I'd still like to know in Visual Studio how can I tell what still had the file open ?
>>>>
>>>>I think you can only do it thru code (and only find the process responsible) : http://stackoverflow.com/questions/860656/using-c-how-does-one-figure-out-what-process-locked-a-file
>>>>
>>>>BTW - best practice is to use "using (stream.......)" which will take care of the dispose() for you (even if there's an exception in the block).
>>>
>>>Thanks Viv. At the moment I'm dealing with a pointy headed person who might not let the bouncycastle dll onto his server.
>>
>>:-{
>>
>>What are his arguments ?
>
>From his email.
>
>Does PGP not provide a dll that does this instead of using a third-party?

I wonder who he means by 'PGP' - IIRC the original Zimmerman company has ended up as part of Symantec ?

> Are you able to review the source code to make sure there is no hidden functionality?

You can review the source - but it would take a *lot* of reviewing to fullfill that requirement :-}
If you were encrypting then, although I'm sure it's not the case, there could be some 'back-door' way of accessing the encrypted file.
OTOH, if you are just using it for decryption what could be the problem ?

>Can you upload the DLL to virus total to make sure no one has flagged it as a malicious file? If there are any updates to the dll then we will need to be alerted or monitor notice boards.

You shouldn't have a problem with that....