IOException: İşlem başka bir işlem tarafından kullanıldığından 'dosya yolu' dosyasına erişemiyor

Bazı kod var ve yürüteceği zaman, bir atar IOExceptionsöyleyerek

İşlem, 'dosyaadı' dosyasına erişemiyor çünkü başka bir işlem tarafından kullanılıyor

Bu ne anlama geliyor ve bu konuda ne yapabilirim?

Sebebi nedir?

Hata mesajı oldukça açık: bir dosyaya erişmeye çalışıyorsunuz ve başka bir işlem (hatta aynı işlem) onunla bir şeyler yapıyor (ve herhangi bir paylaşıma izin vermediğinden) erişilebilir değil.

Hata ayıklama

Özel senaryoya bağlı olarak çözülmesi oldukça kolay (veya anlaşılması oldukça zor) olabilir. Biraz bakalım.

İşleminiz bu dosyaya erişen tek işlemdir. Diğer işlemin kendi işleminiz olduğundan emin olabilirsiniz . Bu dosyayı programınızın başka bir bölümünde açtığınızı biliyorsanız, her şeyden önce her kullanımdan sonra dosya tanıtıcısını düzgün bir şekilde kapatıp kapatmadığınızı kontrol etmeniz gerekir. İşte bu hatayı içeren bir kod örneği:

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

Neyse ki FileStreamuygular IDisposable, bu nedenle tüm kodunuzu bir usingifadeye sarmak kolaydır :

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

Bu model, istisnalar durumunda dosyanın açık bırakılmamasını da sağlar (dosyanın kullanımının nedeni olabilir: bir şeyler ters gitti ve kimse kapatmadı; bir örnek için bu gönderiye bakın ).

Her şey yolunda görünüyorsa (istisnalar olsa bile her zaman açtığınız her dosyayı kapattığınızdan eminseniz) ve birden fazla çalışma iş parçanız varsa, iki seçeneğiniz vardır: dosya erişimini serileştirmek için kodunuzu yeniden çalışın (her zaman yapılabilir değil ve her zaman değil) veya) bir yeniden deneme modeli uygulayın . G / Ç işlemleri için oldukça yaygın bir örüntü: bir şey yapmaya çalışıyorsunuz ve hata durumunda tekrar bekleyip tekrar deniyorsunuz (örneğin kendinize, örneğin Windows Shell'in bir dosyanın kullanımda olduğunu bildirmek için biraz zaman aldığını sordunuz mu? silinemez mi?). C # 'da uygulanması oldukça kolaydır (ayrıca disk G / Ç , ağ ve veritabanı erişimi hakkında daha iyi örneklere bakın ).

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);
    }
}

Lütfen StackOverflow'da sık karşılaştığımız yaygın bir hatayı not edin:

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

Bu durumda ReadAllText()dosya kullanımda olduğundan ( File.Open()önceki satırda) başarısız olur . Dosyayı önceden açmak sadece gereksiz değil aynı zamanda yanlıştır. Aynı herkes için geçerlidir Filebir dönmüyor fonksiyonları kolu : birlikte çalıştığınız dosyaya File.ReadAllText(), File.WriteAllText(), File.ReadAllLines(), File.WriteAllLines()(gibi ve diğerleriFile.AppendAllXyz() fonksiyonları) olacak tüm açık ve kendileri tarafından yakın dosyası.

İşleminiz bu dosyaya erişen tek kişi değil
Eğer işleminiz bu dosyaya erişen tek kişi değilse, etkileşim daha zor olabilir. Yeniden deneme düzeni yardımcı olacaktır (dosya başka biri tarafından açılmamalı ancak öyleyse, kimin ne yaptığını kontrol etmek için Process Explorer gibi bir yardımcı programa ihtiyacınız vardır. ).

Kaçınma yolları

Uygun durumlarda, her zaman kullanmak kullanarak açık dosyaları ifadeleri. Önceki paragrafta belirtildiği gibi, birçok yaygın hatayı önlemenize aktif olarak yardımcı olacaktır ( nasıl kullanılamayacağına ilişkin bir örnek için bu gönderiye bakın ).

Mümkünse, belirli bir dosyaya kimin erişimi olduğunu kararlaştırmaya çalışın ve birkaç bilinen yöntemle erişimi merkezileştirin. Örneğin, programınızın okuduğu ve yazdığı bir veri dosyanız varsa, tüm G / Ç kodlarını tek bir sınıfta kutlamanız gerekir. Hata ayıklamayı kolaylaştıracaktır (çünkü oraya her zaman bir kesme noktası koyabilir ve kimin ne yaptığını görebilirsiniz) ve ayrıca çoklu erişim için bir senkronizasyon noktası olacaktır (gerekirse).

G / Ç işlemlerinin her zaman başarısız olabileceğini unutmayın, yaygın bir örnek şudur:

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

Eğer birisi sonra dosyayı siler File.Exists()ama önce File.Delete(), o zaman bir atacağım IOExceptionsen yanlış güvenli hissedebilirsiniz bir yerde.

Mümkün olduğunda, bir yeniden deneme deseni uygulayın ve kullanıyorsanız FileSystemWatcher, erteleme eylemini düşünün (çünkü bildirim alırsınız, ancak bir uygulama yalnızca bu dosyayla çalışıyor olabilir).

Gelişmiş senaryolar
Her zaman bu kadar kolay değildir, bu nedenle erişimi başka biriyle paylaşmanız gerekebilir. Örneğin, baştan okuyup sonuna kadar yazıyorsanız, en az iki seçeneğiniz vardır.

1) FileStreamuygun senkronizasyon fonksiyonları ile aynı paylaşın (çünkü iş parçacığı için güvenli değildir ). Bkz bu ve buBir örnek için gönderilere .

2) FileShareOS'ye diğer işlemlerin (veya kendi işleminizin diğer bölümlerinin) aynı dosyaya aynı anda erişmesine izin vermesini bildirmek için numaralandırma kullanın.

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

Bu örnekte, yazmak için bir dosyanın nasıl açılacağını ve okumak için nasıl paylaşılacağını gösterdim; Çakışmaları okurken ve yazarken tanımsız veya geçersiz verilerle sonuçlandığını lütfen unutmayın. Bu, okurken ele alınması gereken bir durumdur. Ayrıca, streamiş parçacığının güvenliğine erişim sağlamadığını unutmayın, bu nedenle erişim bir şekilde eşitlenmedikçe bu nesne birden çok iş parçacığıyla paylaşılamaz (önceki bağlantılara bakın). Diğer paylaşım seçenekleri mevcuttur ve daha karmaşık senaryolar açarlar. Bakınız MSDN Daha fazla ayrıntı için.

Genel olarak N süreçleri aynı dosyadan birlikte okuyabilir, ancak yalnızca bir tanesi yazmalı, kontrollü bir senaryoda eşzamanlı yazıları bile etkinleştirebilirsiniz, ancak bu cevap içindeki birkaç metin paragrafında genelleştirilemez.

Başka bir işlem tarafından kullanılan bir dosyanın kilidini açmak mümkün müdür ? Her zaman güvenli değil ve o kadar kolay değil ama evet, mümkün .

FileShare kullanmak , başka bir işlem tarafından açılsa bile dosyayı açma sorunumu çözdü.

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

Bir resim yüklenirken bir sorun oluştu ve görüntüyü silemedi ve bir çözüm buldu. gl hf

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

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

//later...

File.Delete(filePath); //now works

Bu hatayı aldım çünkü File.Move bir dosya adı olmadan bir dosya yoluna, hedefte tam yolu belirtmeniz gerekiyor.

Hata, başka bir işlemin dosyaya erişmeye çalıştığını gösterir. Belki siz ya da başkası yazmaya çalışırken siz açmışsınızdır. "Oku" veya "Kopyala" genellikle buna neden olmaz, ancak üzerine yazma veya silme çağrısı yapar.

Diğer cevapların belirttiği gibi, bundan kaçınmak için bazı temel şeyler vardır:

1. Gelen FileStreamoperasyonlarda, bir koyun usingbir ile bloğun FileShare.ReadWriteerişim modlarının.

   Örneğin:

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

   Kullanırsanız bunun FileAccess.ReadWritemümkün olmadığını unutmayın FileMode.Append.

2. File.SaveAsDosya kullanımdayken bir girdi akışı kullanırken bu sorunla karşılaştım . Benim durumumda buldum, aslında hiç geri dosya sistemine kaydetmek zorunda değildi, bu yüzden sadece bunu kaldırma sona erdi, ama büyük olasılıkla kod gibi bir usingifadede bir FileStream oluşturmayı deneyebilirdim FileAccess.ReadWriteyukarıda.

3. Verilerinizi farklı bir dosya olarak kaydetmek ve artık kullanılmadığı tespit edildiğinde eskisini silmek için geri dönmek, ardından başarıyla kaydedilmiş olanı orijinal dosyanın adına yeniden adlandırmak bir seçenektir. Kullanımda olan dosyayı nasıl test edeceğiniz,

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

   aşağıdaki kodumda yer alır ve değiştirmek istediğinizde düzenli olarak izlemek ve silmek istediğiniz belirli bir dosyanız varsa, bir Windows hizmetinde, bir döngüde yapılabilir. Her zaman aynı dosyaya sahip değilseniz, hizmetin her zaman dosya adlarını kontrol ettiği bir metin dosyası veya veritabanı tablosu güncellenebilir ve daha sonra açıkladığım gibi süreçleri kontrol eder ve daha sonra süreç öldürme ve silme işlemini gerçekleştirir. sonraki seçenek. İşlemlerin silinmesini ve sonlandırılmasını gerçekleştirmek için, elbette, belirli bir bilgisayarda Yönetici ayrıcalıklarına sahip bir hesap kullanıcı adı ve parolasına ihtiyacınız olacağını unutmayın.

4. Bir dosyayı kaydetmeye çalışırken kullanılıp kullanılmayacağını bilmediğinizde, kaydetmeden önce Word gibi, Word gibi kullanabilen tüm işlemleri kapatabilirsiniz.

   Yerel ise, bunu yapabilirsiniz:

   ProcessHandler.localProcessKill("winword.exe");

   Uzaksa, bunu yapabilirsiniz:

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

   burada txtUserNameformundadır DOMAIN\user.

5. Diyelim ki dosyayı kilitleyen işlem adını bilmiyorsunuz. Sonra bunu yapabilirsiniz:

   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);
   }

   Not file: UNC yol olmalıdır \\computer\share\yourdoc.docxsırayla Processaçıldığını gösteriyor hangi bilgisayarı anlamaya ve p.MachineNamegeçerli olması.

   Aşağıda, bu işlevlerin başvurduğu sınıf başvurusu vardır System.Management. Kod ilk olarak Eric J. tarafından yazılmıştır :

   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;
   
       }
   }

Bu konudaki diğer yanıtların işaret ettiği gibi, bu hatayı gidermek için, kodu nerede kilitlediğinizi anlamak için kodu dikkatlice incelemeniz gerekir.

Benim durumumda, taşıma işlemini gerçekleştirmeden önce dosyayı e-posta eki olarak gönderiyordum.

SMTP istemcisi e-postayı göndermeyi bitirene kadar dosya birkaç saniye kilitlendi.

Benimsediğim çözüm önce dosyayı taşımak ve sonra e-postayı göndermekti. Bu benim için problemi çözdü.

Daha önce Hudson tarafından belirtildiği gibi bir başka olası çözüm, nesneyi kullanımdan sonra atmak olurdu.

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
            }
} 

Aynı hataya neden olan aşağıdaki senaryo vardı:

• Dosyaları sunucuya yükleyin
• Sonra yüklendikten sonra eski dosyalardan kurtulun

Dosyaların çoğu boyut olarak küçüktü, ancak birkaçı büyüktü ve bu yüzden dosyaları silmeye çalışmak dosyaya erişememe hatasıyla sonuçlandı .

Ancak çözümü bulmak kolay değildi, "görevin tamamlanmasını beklemek " kadar basitti :

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

Aşağıdaki kod bu sorunu çözmek, ama ben öncelikle bu soruna neyin neden olduğunu anlamak ve kodu değiştirerek bulabileceğiniz çözümü denemek gerekir öneririz

Bu sorunu çözmek için başka bir yol verebilirim ama daha iyi bir çözüm kodlama yapınızı kontrol etmek ve bunun ne olduğunu analiz etmeye çalışmaktır, eğer herhangi bir çözüm bulamazsanız aşağıdaki kodla gidebilirsiniz

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;
    }
 }