IOException: процесс не может получить доступ к файлу «путь к файлу», поскольку он используется другим процессом


172

У меня есть некоторый код, и когда он выполняется, он бросает IOException, говоря, что

Процесс не может получить доступ к файлу «имя файла», потому что он используется другим процессом

Что это значит, и что я могу с этим поделать?


1
Посмотрите этот вопрос, чтобы узнать, как найти другой процесс, который использует файл.
Стоми

Ответы:


274

В чем причина?

Сообщение об ошибке довольно ясно: вы пытаетесь получить доступ к файлу, и он недоступен, потому что другой процесс (или даже тот же самый процесс) что-то делает с ним (и он не разрешил какой-либо обмен).

Отладка

Это может быть довольно легко решить (или довольно сложно понять), в зависимости от вашего конкретного сценария. Давайте посмотрим некоторые.

Ваш процесс является единственным для доступа к этому файлу.
Вы уверены, что другой процесс - ваш собственный процесс. Если вы знаете, что открываете этот файл в другой части вашей программы, то прежде всего вы должны проверить, правильно ли вы закрываете дескриптор файла после каждого использования. Вот пример кода с этой ошибкой:

var stream = new FileStream(path, FileAccess.Read);
var reader = new StreamReader(stream);
// Read data from this file, when I'm done I don't need it any more
File.Delete(path); // IOException: file is in use

К счастью, FileStreamреализует IDisposable, поэтому легко обернуть весь ваш код в usingоператор:

using (var stream = File.Open("myfile.txt", FileMode.Open)) {
    // Use stream
}

// Here stream is not accessible and it has been closed (also if
// an exception is thrown and stack unrolled

Этот шаблон также гарантирует, что файл не останется открытым в случае исключений (это может быть причиной того, что файл используется: что-то пошло не так, и никто не закрыл его; см. Этот пост для примера).

Если все выглядит нормально (вы уверены, что всегда закрываете каждый файл, который открываете, даже в случае исключений) и у вас есть несколько рабочих потоков, тогда у вас есть два варианта: переработать код для сериализации доступа к файлу (не всегда выполнимо и не всегда хотел) или применить шаблон повторов . Это довольно распространенный шаблон для операций ввода-вывода: вы пытаетесь что-то сделать, а в случае ошибки вы ждете и пытаетесь снова (вы спрашивали себя, например, почему Windows Shell требуется некоторое время, чтобы сообщить вам, что файл используется и нельзя удалить?). В C # это довольно просто реализовать (см. Также лучшие примеры дискового ввода-вывода , работы в сети и доступа к базе данных ).

private const int NumberOfRetries = 3;
private const int DelayOnRetry = 1000;

for (int i=1; i <= NumberOfRetries; ++i) {
    try {
        // Do stuff with file
        break; // When done we can break loop
    }
    catch (IOException e) when (i <= NumberOfRetries) {
        // You may check error code to filter some exceptions, not every error
        // can be recovered.
        Thread.Sleep(DelayOnRetry);
    }
}

Обратите внимание на распространенную ошибку, которую мы очень часто видим в StackOverflow:

var stream = File.Open(path, FileOpen.Read);
var content = File.ReadAllText(path);

В этом случае ReadAllText()произойдет сбой, потому что файл используется ( File.Open()в строке ранее). Открывать файл заранее не только не нужно, но и неправильно. То же самое относится и ко всем Fileфункциям , которые не возвращают дескриптор к файлу вы работаете: File.ReadAllText(), File.WriteAllText(), File.ReadAllLines(), File.WriteAllLines()и другие (например , File.AppendAllXyz()функции) будут все открывать и закрывать файл самостоятельно.

Ваш процесс не единственный, кто получает доступ к этому файлу.
Если ваш процесс не единственный, кто получает доступ к этому файлу, взаимодействие может быть более сложным. Шаблон повторных попыток поможет (если файл не должен быть открыт кем - либо еще , но это, то вам необходимо утилита , как Process Explorer , чтобы проверить , кто делает то , что ).

Способов избежать

При необходимости всегда используйте операторы для открытия файлов. Как было сказано в предыдущем абзаце, это поможет вам избежать многих распространенных ошибок (см. Этот пост, где показано, как его не использовать ).

Если возможно, попытайтесь решить, кому принадлежит доступ к определенному файлу, и централизовать доступ несколькими известными способами. Если, например, у вас есть файл данных, в котором ваша программа читает и пишет, вы должны поместить весь код ввода / вывода в один класс. Это облегчит отладку (потому что вы всегда можете поставить точку останова и посмотреть, кто что делает), а также будет точкой синхронизации (если требуется) для множественного доступа.

Не забывайте, что операции ввода-вывода всегда могут быть неудачными, общий пример:

if (File.Exists(path))
    File.Delete(path);

Если кто-то удалит файл после, File.Exists()но до этого File.Delete(), он будет помещен IOExceptionв место, где вы можете ошибочно чувствовать себя в безопасности.

Когда это возможно, примените шаблон повтора и, если вы используете FileSystemWatcher, рассмотрите возможность отложить действие (потому что вы получите уведомление, но приложение все еще может работать исключительно с этим файлом).

Расширенные сценарии
Это не всегда так просто, поэтому вам может потребоваться поделиться доступом с кем-то еще. Если, например, вы читаете от начала и пишете до конца, у вас есть как минимум два варианта.

1) делить то же самое FileStreamс правильными функциями синхронизации (потому что это не потокобезопасно ). Смотрите этот и этот пост для примера.

2) использовать FileShareперечисление, чтобы указать ОС разрешить другим процессам (или другим частям вашего собственного процесса) одновременно обращаться к одному и тому же файлу.

using (var stream = File.Open(path, FileMode.Open, FileAccess.Write, FileShare.Read))
{
}

В этом примере я показал, как открыть файл для записи и поделиться для чтения; обратите внимание, что при чтении и записи перекрытий это приводит к неопределенным или недействительным данным. Это ситуация, которая должна быть обработана при чтении. Также обратите внимание, что это не делает доступ к streamпотокобезопасным, поэтому этот объект не может быть совместно использован несколькими потоками, если доступ не синхронизирован каким-либо образом (см. Предыдущие ссылки). Другие варианты обмена доступны, и они открывают более сложные сценарии. Пожалуйста, обратитесь к MSDN для более подробной информации.

В общем случае N процессов могут читать из одного и того же файла все вместе, но писать должен только один, в контролируемом сценарии вы можете даже разрешить одновременные записи, но это не может быть обобщено в нескольких текстовых параграфах внутри этого ответа.

Можно ли разблокировать файл, используемый другим процессом? Это не всегда безопасно и не так просто, но да, это возможно .


Я не знаю, что не так с моим кодом, я использую блоки, но все же есть ошибка, говорящая о том, что файл используется, когда я пытаюсь удалить его.
Джамшайд Кямран

Нет, на самом деле у меня есть элемент управления таймером, который делает, кроме таймера, если я вызову функцию еще раз, она выдаст исключение. в основном я расшифровываю файл в другой текстовый файл, после чего удаляю только что созданный файл, который выдает исключение при удалении!
Джамшайд Кямран

3
@ جمشیدکامران Зачем создавать файл с содержимым, которое есть в вашем коде, а затем удалять его? Кажется странным создавать файл в первую очередь. Поскольку вы не отправляли код, мы не знаем, что вы делаете. Но когда вы создаете свой файл, если вы делаете это с File.Create(path), вы должны добавить .Close()в конце этого, прежде чем писать в него. Подобные подводные камни, помимо usingоператоров для записи файлов, а затем удаления после них. Вы должны опубликовать код в своем вопросе о том, как вы создаете и удаляете свой файл. Но, вероятно, соответствует тому, что упомянуто выше.
vapcguy

Мой код использует, Directory.SetCreationTimeUTC()но он не работает, когда File Explorer открыт, утверждая, что к каталогу обращается другой процесс. Как мне справиться с этой ситуацией?
Кайл Делани

1
@KyleDelaney Я бы сказал, что вам нужно подождать, пока папка не будет закрыта, если это не несколько секунд, тогда все быстро станет сложным (сохраните фоновую очередь с ожидающими операциями? Наблюдатель за файловой системой? Опрос?) Вы можете захотеть опубликовать вопрос с более подробной информацией для специального ответа
Адриано

29

Использование FileShare исправило мою проблему открытия файла, даже если он был открыт другим процессом.

using (var stream = File.Open(path, FileMode.Open, FileAccess.Write, FileShare.ReadWrite))
{
}

9

Возникла проблема при загрузке изображения, и он не мог удалить его и нашел решение. гл хф

//C# .NET
var image = Image.FromFile(filePath);

image.Dispose(); // this removes all resources

//later...

File.Delete(filePath); //now works

2
Если вы удаляете файл, вам сначала нужно удалить объект изображения.
Shazia

1
Хорошо, я искал это решение. У меня также была проблема с функцией Image.FromFile.
наследник

1
@thescion :) np
Хадсон

1
Это сработало для меня и решило мою проблему. Я хотел обработать папку файлов Tiff, преобразовать их в потоки byte [] и отправить в службу, а затем переместить папку файлов Tiff в папку «Обработанные» архива. Image.FromFile устанавливает блокировку файла Tiff и не освобождает его своевременно, поэтому, когда я переместил файлы Tiff и содержащую их папку, я получил ошибку «используется другим процессом», так как блокировки все еще были на месте. Выполнение .Release сразу после получения байтов файла Tiff полностью решило проблему с заблокированным файлом.
Developer63

4

Я получил эту ошибку, потому что я делал File.Move к пути к файлу без имени файла, необходимо указать полный путь в месте назначения.


И не только без имени файла. Недопустимое (целевое) имя файла - в моем случае "... \ file." - выдаст ту же самую глупую ошибку и укажет вам неправильное направление на полдня!
Ник Вестгейт

3

Ошибка указывает, что другой процесс пытается получить доступ к файлу. Может быть, вы или кто-то еще открыли его, когда вы пытаетесь писать в него. «Чтение» или «Копирование» обычно не вызывают этого, но запись в него или вызов удаления его приведет к этому.

Есть несколько основных вещей, чтобы избежать этого, как уже упоминалось в других ответах:

  1. В FileStreamоперациях поместите его в usingблок с FileShare.ReadWriteрежимом доступа.

    Например:

    using (FileStream stream = File.Open(path, FileMode.Open, FileAccess.Write, FileShare.ReadWrite))
    {
    }
    

    Обратите внимание, что FileAccess.ReadWriteэто невозможно, если вы используете FileMode.Append.

  2. Я столкнулся с этой проблемой, когда я использовал поток ввода, чтобы сделать, File.SaveAsкогда файл использовался. В моем случае я обнаружил, что мне вообще не нужно было сохранять его обратно в файловую систему, поэтому я просто удалил его, но, возможно, я мог бы попытаться создать FileStream в usingвыражении FileAccess.ReadWrite, очень похожем на код выше.

  3. Сохраните ваши данные в другом файле и вернитесь, чтобы удалить старый файл, если он больше не используется, а затем переименовать тот, который был успешно сохранен, в имя исходного файла. Как вы проверяете файл, который используется, осуществляется с помощью

    List<Process> lstProcs = ProcessHandler.WhoIsLocking(file);

    строка в моем коде ниже, и может быть сделано в службе Windows, в цикле, если у вас есть определенный файл, который вы хотите регулярно просматривать и удалять, когда вы хотите заменить его. Если у вас не всегда один и тот же файл, можно обновить текстовый файл или таблицу базы данных, чтобы служба всегда проверяла имена файлов, а затем выполняла эту проверку для процессов и впоследствии выполняла уничтожение и удаление процессов, как я описываю в следующем варианте. Обратите внимание, что вам понадобится имя пользователя и пароль учетной записи, которые имеют права администратора на данном компьютере, конечно, для выполнения удаления и завершения процессов.

  4. Если вы не знаете, будет ли файл использоваться при попытке сохранить его, вы можете закрыть все процессы, которые могут его использовать, например, Word, если это документ Word, до сохранения.

    Если это локально, вы можете сделать это:

    ProcessHandler.localProcessKill("winword.exe");

    Если он удаленный, вы можете сделать это:

    ProcessHandler.remoteProcessKill(computerName, txtUserName, txtPassword, "winword.exe");

    где txtUserNameнаходится в форме DOMAIN\user.

  5. Допустим, вы не знаете имя процесса, который блокирует файл. Затем вы можете сделать это:

    List<Process> lstProcs = new List<Process>();
    lstProcs = ProcessHandler.WhoIsLocking(file);
    
    foreach (Process p in lstProcs)
    {
        if (p.MachineName == ".")
            ProcessHandler.localProcessKill(p.ProcessName);
        else
            ProcessHandler.remoteProcessKill(p.MachineName, txtUserName, txtPassword, p.ProcessName);
    }

    Обратите внимание, что это fileдолжен быть путь UNC: \\computer\share\yourdoc.docxдля того, Processчтобы выяснить, на каком компьютере он находится, и p.MachineNameбыть действительным.

    Ниже приведен класс, используемый этими функциями, который требует добавления ссылки System.Management. Код был изначально написан Эриком Дж . :

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.Threading.Tasks;
    using System.Runtime.InteropServices;
    using System.Diagnostics;
    using System.Management;
    
    namespace MyProject
    {
        public static class ProcessHandler
        {
            [StructLayout(LayoutKind.Sequential)]
            struct RM_UNIQUE_PROCESS
            {
                public int dwProcessId;
                public System.Runtime.InteropServices.ComTypes.FILETIME ProcessStartTime;
            }
    
            const int RmRebootReasonNone = 0;
            const int CCH_RM_MAX_APP_NAME = 255;
            const int CCH_RM_MAX_SVC_NAME = 63;
    
            enum RM_APP_TYPE
            {
                RmUnknownApp = 0,
                RmMainWindow = 1,
                RmOtherWindow = 2,
                RmService = 3,
                RmExplorer = 4,
                RmConsole = 5,
                RmCritical = 1000
            }
    
            [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
            struct RM_PROCESS_INFO
            {
                public RM_UNIQUE_PROCESS Process;
    
                [MarshalAs(UnmanagedType.ByValTStr, SizeConst = CCH_RM_MAX_APP_NAME + 1)]
                public string strAppName;
    
                [MarshalAs(UnmanagedType.ByValTStr, SizeConst = CCH_RM_MAX_SVC_NAME + 1)]
                public string strServiceShortName;
    
                public RM_APP_TYPE ApplicationType;
                public uint AppStatus;
                public uint TSSessionId;
                [MarshalAs(UnmanagedType.Bool)]
                public bool bRestartable;
            }
    
            [DllImport("rstrtmgr.dll", CharSet = CharSet.Unicode)]
            static extern int RmRegisterResources(uint pSessionHandle,
                                                UInt32 nFiles,
                                                string[] rgsFilenames,
                                                UInt32 nApplications,
                                                [In] RM_UNIQUE_PROCESS[] rgApplications,
                                                UInt32 nServices,
                                                string[] rgsServiceNames);
    
            [DllImport("rstrtmgr.dll", CharSet = CharSet.Auto)]
            static extern int RmStartSession(out uint pSessionHandle, int dwSessionFlags, string strSessionKey);
    
            [DllImport("rstrtmgr.dll")]
            static extern int RmEndSession(uint pSessionHandle);
    
            [DllImport("rstrtmgr.dll")]
            static extern int RmGetList(uint dwSessionHandle,
                                        out uint pnProcInfoNeeded,
                                        ref uint pnProcInfo,
                                        [In, Out] RM_PROCESS_INFO[] rgAffectedApps,
                                        ref uint lpdwRebootReasons);
    
            /// <summary>
            /// Find out what process(es) have a lock on the specified file.
            /// </summary>
            /// <param name="path">Path of the file.</param>
            /// <returns>Processes locking the file</returns>
            /// <remarks>See also:
            /// http://msdn.microsoft.com/en-us/library/windows/desktop/aa373661(v=vs.85).aspx
            /// http://wyupdate.googlecode.com/svn-history/r401/trunk/frmFilesInUse.cs (no copyright in code at time of viewing)
            /// 
            /// </remarks>
            static public List<Process> WhoIsLocking(string path)
            {
                uint handle;
                string key = Guid.NewGuid().ToString();
                List<Process> processes = new List<Process>();
    
                int res = RmStartSession(out handle, 0, key);
                if (res != 0) throw new Exception("Could not begin restart session.  Unable to determine file locker.");
    
                try
                {
                    const int ERROR_MORE_DATA = 234;
                    uint pnProcInfoNeeded = 0,
                        pnProcInfo = 0,
                        lpdwRebootReasons = RmRebootReasonNone;
    
                    string[] resources = new string[] { path }; // Just checking on one resource.
    
                    res = RmRegisterResources(handle, (uint)resources.Length, resources, 0, null, 0, null);
    
                    if (res != 0) throw new Exception("Could not register resource.");
    
                    //Note: there's a race condition here -- the first call to RmGetList() returns
                    //      the total number of process. However, when we call RmGetList() again to get
                    //      the actual processes this number may have increased.
                    res = RmGetList(handle, out pnProcInfoNeeded, ref pnProcInfo, null, ref lpdwRebootReasons);
    
                    if (res == ERROR_MORE_DATA)
                    {
                        // Create an array to store the process results
                        RM_PROCESS_INFO[] processInfo = new RM_PROCESS_INFO[pnProcInfoNeeded];
                        pnProcInfo = pnProcInfoNeeded;
    
                        // Get the list
                        res = RmGetList(handle, out pnProcInfoNeeded, ref pnProcInfo, processInfo, ref lpdwRebootReasons);
                        if (res == 0)
                        {
                            processes = new List<Process>((int)pnProcInfo);
    
                            // Enumerate all of the results and add them to the 
                            // list to be returned
                            for (int i = 0; i < pnProcInfo; i++)
                            {
                                try
                                {
                                    processes.Add(Process.GetProcessById(processInfo[i].Process.dwProcessId));
                                }
                                // catch the error -- in case the process is no longer running
                                catch (ArgumentException) { }
                            }
                        }
                        else throw new Exception("Could not list processes locking resource.");
                    }
                    else if (res != 0) throw new Exception("Could not list processes locking resource. Failed to get size of result.");
                }
                finally
                {
                    RmEndSession(handle);
                }
    
                return processes;
            }
    
            public static void remoteProcessKill(string computerName, string userName, string pword, string processName)
            {
                var connectoptions = new ConnectionOptions();
                connectoptions.Username = userName;
                connectoptions.Password = pword;
    
                ManagementScope scope = new ManagementScope(@"\\" + computerName + @"\root\cimv2", connectoptions);
    
                // WMI query
                var query = new SelectQuery("select * from Win32_process where name = '" + processName + "'");
    
                using (var searcher = new ManagementObjectSearcher(scope, query))
                {
                    foreach (ManagementObject process in searcher.Get()) 
                    {
                        process.InvokeMethod("Terminate", null);
                        process.Dispose();
                    }
                }            
            }
    
            public static void localProcessKill(string processName)
            {
                foreach (Process p in Process.GetProcessesByName(processName))
                {
                    p.Kill();
                }
            }
    
            [DllImport("kernel32.dll")]
            public static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName, int dwFlags);
    
            public const int MOVEFILE_DELAY_UNTIL_REBOOT = 0x4;
    
        }
    }

2

Как указывалось в других ответах в этой теме, для устранения этой ошибки вам необходимо тщательно проверить код, чтобы понять, где файл блокируется.

В моем случае я отправлял файл в виде вложения электронной почты перед выполнением операции перемещения.

Таким образом, файл был заблокирован на пару секунд, пока SMTP-клиент не завершил отправку электронного письма.

Я принял решение сначала переместить файл, а затем отправить электронное письмо. Это решило проблему для меня.

Другое возможное решение, как указывалось ранее Хадсоном, заключалось бы в утилизации объекта после использования.

public static SendEmail()
{
           MailMessage mMailMessage = new MailMessage();
           //setup other email stuff

            if (File.Exists(attachmentPath))
            {
                Attachment attachment = new Attachment(attachmentPath);
                mMailMessage.Attachments.Add(attachment);
                attachment.Dispose(); //disposing the Attachment object
            }
} 

Если файл используется, File.Move()он не будет работать и выдает ту же ошибку. Если я просто добавляю файл в электронное письмо, я не думаю, что он будет ошибочным при использовании во время Attachments.Add()операции, потому что это всего лишь операция копирования. Если это произошло по какой-либо причине, вы можете скопировать его в каталог Temp, прикрепить копию и впоследствии удалить скопированный файл. Но я не думаю, что если ОП захочет изменить файл и использовать его, то этот вид решения (код которого вы не показали, только часть приложения) сработал бы. .Dispose()это всегда хорошая идея, но здесь она не актуальна, если файл не открыт в предыдущей операции.
vapcguy

1

У меня был следующий сценарий, который вызывал ту же ошибку:

  • Загрузить файлы на сервер
  • Затем избавьтесь от старых файлов после их загрузки

Большинство файлы были небольшими по размеру, однако, некоторые из них были большими, и поэтому попытка удалить те привели к нет доступа к файлу ошибки.

Было нелегко найти решение, однако, решение было таким же простым, как ожидание «завершения задачи»:

using (var wc = new WebClient())
{
   var tskResult = wc.UploadFileTaskAsync(_address, _fileName);
   tskResult.Wait(); 
}

-1

Приведенный ниже код решает эту проблему, но я предлагаю Прежде всего вам нужно понять, что является причиной этой проблемы, и попробовать решение, которое вы можете найти, изменив код

Я могу дать другой способ решения этой проблемы, но лучшее решение - проверить структуру вашего кода и попытаться проанализировать, что делает это, если вы не нашли никакого решения, вы можете воспользоваться этим кодом ниже.

try{
Start:
///Put your file access code here


}catch (Exception ex)
 {
//by anyway you need to handle this error with below code
   if (ex.Message.StartsWith("The process cannot access the file"))
    {
         //Wait for 5 seconds to free that file and then start execution again
         Thread.Sleep(5000);
         goto Start;
    }
 }

1
Несколько проблем с этим кодом: 1) если вам нужно позвонить GC.*(), возможно, у вас другие проблемы с вашим кодом. 2) Сообщение локализовано и хрупко , вместо этого используйте HRESULT. 3) Вы можете спать с Task.Delay()(и десять секунд во многих случаях как-то чрезмерно). 4) У вас нет условия выхода: этот код может зависнуть навсегда. 5) Тебе здесь точно не нужно goto. 6) Поймать, Exceptionкак правило, плохая идея, в данном случае также потому, что ... 6) Если что-то случится, вы глотаете ошибку.
Адриано Репетти

@AdrianoRepetti мой первый комментарий сказал, что не используйте этот код, попробуйте найти другое решение, это будет последний вариант, и в любом случае, если эта ошибка произойдет, код остановится, но если вы обрабатываете эту ошибку, система будет ждать освобождения файла и после этого он запустится работает, и я не сталкиваюсь с другими проблемами с GC. * при использовании этого кода. У меня уже есть рабочая система с этим кодом, поэтому я написал, что может быть полезным для кого-то.
Пепел

Я бы сказал , чтобы не использовать этот код когда - либо (из точек , которые я упоминал выше) , и я не считаю эту работу в системе прода , но это только мое POV. Не стесняйтесь не соглашаться!
Адриано Репетти

1) Я использовал службу Windows, где я использовал это, и я использовал GC. * До этого у меня не возникало никаких проблем с этим2) да, HRESULT может быть лучшим вариантом с точки зрения кодирования стандарта3) Зависит от ситуации, которую вы можете дать время, которое я только что отредактировал до 5 секунд 4) в любом случае, лучше, чтобы система ждала некоторое время, чтобы освободить ресурс, а не останавливала систему с ошибкой 5) да, я согласна с вами, обработка исключений не всегда хорошая идея, но если ваш фрагмент кода мал и вы знаете, что здесь я могу обработать исключение, тогда это решение для вас.
Пепел

Смотрите также: docs.microsoft.com/en-us/archive/blogs/ricom/… . Единственный (и я подчеркиваю только) случай, который мне нужно было использовать GC.Collect(), был при работе с некоторыми объектами COM.
Адриано Репетти
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.