Access denied error

I am trying to delete the excel file from a specipic location . but can't deleting. having error :

Access to the path 'C:\mypath\sample.xlsx' is denied.

I write a code as :

protected void imgbtnImport_Click(object sender, ImageClickEventArgs e)
{

    try
    {
        string strApplicationPath = HttpContext.Current.Request.MapPath(HttpContext.Current.Request.ApplicationPath);
        string strXLSto开发者_Python百科redDirectoryPath = strApplicationPath + "/Information Documents/";
        DirectoryInfo di = new DirectoryInfo(strXLStoredDirectoryPath);
        string fileName = flUpldSelectFile.FileName;
        if (!File.Exists(strXLStoredDirectoryPath))
        {
            Directory.CreateDirectory(strXLStoredDirectoryPath);

            di.Attributes = FileAttributes.Normal;
        }
        string strCreateXLFileDestinationPath = strXLStoredDirectoryPath + fileName;
        if (File.Exists(strCreateXLFileDestinationPath))
        {
            File.Delete(strCreateXLFileDestinationPath);
        }

        flUpldSelectFile.SaveAs(strCreateXLFileDestinationPath);           
        di.Attributes = FileAttributes.ReadOnly;
    }
    catch (Exception)
    {            
        throw;
    }
}

please guide.........

-*********************************************************************** Still problem there . it is not resolved . getting UnauthorizedAccessException. as access denied to deleting file. I m tired now . please help; I tried many things..please help -*********************************************************************** Is may be iffect of VSS ? i am using that

UPDATE:

Part of your issue might be what is saving/creating this file. If you're using a built in "Save" or "SaveAs" feature the underlying file stream might still have a lock on the file. writing your own save logic with a FileStream wrapped in a Using statement will help dispose the stream right when you're done thus allowing you to further manipulate the file within the same context.

if flUpldSelectFile.SaveAs(strCreateXLFileDestinationPath); is the only logic that saves the file then get rid of the built in SaveAs functionality. write your own save logic using a FileStream wrapped in a Using block.

In your example i can't see what flUpldSelectFile is so i am assuming it is a System.Web.UI.WebControls.FileUpload control. Here is an example of rolling your own save logic.

using (FileStream fs = new FileStream(strCreateXLFileDestinationPath, FileMode.Create))
{        
    byte[] buffer = flUpldSelectFile.FileBytes;
    fs.Write(buffer, 0, buffer.Length);
}

As stated previously, use this tool to find out if there is a lock on the file by another process.

ORIGINAL

Pop open this wonderful tool and search for that file to see who/what has it locked

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

If your code is working under IIS , Note that ASPNET user doesn't have access to computer files, you should give access to it, that is not recommended, or store you files in the place where ASPNET user have access

see here

Try a combination of these 2 steps:

1. Set the IIS application pool to run under an account with privileges such as a domain account or local user account (not a default account like local service or local system). Instructions for IIS7.

2. Turn impersonation on in the web.config file, in the <system.web> section:
   <identity impersonate="true"/>

   <identity impersonate="true" userName="contoso\Jane" password="password"/>

I think the message is clear, you do not have authorization to delete the file or it is opened by another application. I bet 2$ you can't delete the file manually either.

As others have said, this is because IIS runs your application as a user with restricted access rights. This is a wise security precaution, so that your system is less vulnerable to malicious attacks.

What you need to do is to give the ASPNET user access to the specific folder. You do that from the security tab in the properties of a folder. The user you need to give full control to depends on the version of IIS you are using. In Windows XP it is ASPNET. In Windows Server 2003, 2008 and Windows Vista, 7 it is NETWORK_SERVICE.

See also this question for more details.

Make sure the file isn't opened or locked by another user/process.

Make sure ASPNET user has access on the file\folder (check the file\folder's property using windows explorer and go to security tab. check if ASPNET user is added there).

One of two things are happening. Either the file is already open, or the permission of the user running IIS does not have the proper permissions.

Either way, this utility ProcMon: Proc Mon will help you determine the issue. Run ProcMon, kick off your process to try and delete the file. Then go back to procmon. Hit Ctrl-E to turn off the capture, then Ctrl-F to find. Enter the name of the file you're trying to delete. Then once you've found the correct line with the access denied (or similar error) Double click on the the line to get further information. When you click on the Process tab, it will show you the exact user that is trying to delete the file.

So, if it is a file permission issue, you now know the exact user, and can therefore go to the file system right click on the folder that houses the file you are trying to delete, and grant that user permissions to read/write/update that folder.

Second, if the file is locked open instead of a permissions issue, you will have to find out what process is holding open the file. If you are also writing this file in another part of your code, perhaps you are not closing it properly or releasing the object reference.

Have you verified that the file does not have the read-only attribute set?

I don't think we have enough info to be helpful. What is the security context (identity) during the call to Delete? Is the application impersonating the end user? If it is, how are they authenticated? If by Windows / Active Directory, then you'll need to verify that user's access rights to the specific file. If by Forms login, then you should probably not impersonate and verify that the AppPool's security context has the appropriate access rights.