Arquivo ocupado por outro processo? Como verificar em C# (tutorial)

O arquivo teimosamente não se deixa abrir? Entendendo o "file in use" em C#

Todo desenvolvedor C# mais cedo ou mais tarde enfrenta esta situação: você tenta ler um arquivo, abri-lo para escrita ou simplesmente copiá-lo, e o programa falha com IOException. A mensagem geralmente soa como: "The process cannot access the file because it is being used by another process". Soa familiar? Se você já se perguntou «Is there a way to check if a file is in use?» — você veio ao lugar certo. Neste tutorial, vamos abordar não apenas conselhos abstratos, mas soluções reais e funcionais em C# que vão salvar seus nervos e tempo.

Este problema é um verdadeiro flagelo para iniciantes. Parece que o arquivo deveria estar "livre", mas o sistema insiste em negar o acesso. Na maioria das vezes, isso acontece quando o arquivo:

• Está aberto em outro programa (bloco de notas, Excel, IDE).
• Já foi capturado pela sua própria aplicação em outra thread.
• Está bloqueado pelo antivírus ou por um processo do sistema.

Mas o segredo principal que você deve aprender agora: no .NET puro não existe um método mágico File.IsInUse(). Tudo o que podemos fazer é tentar abrir o arquivo e tratar o erro adequadamente. Parece rude? Mas é confiável. Vamos nessa!

Por que não confiar no Google: desmascarando mitos

Se você pesquisar a resposta para a pergunta «como verificar se um arquivo está em uso», encontrará vários conselhos como "use File.GetAccessControl()" ou "verifique via WMI". Esqueça. A primeira opção é sobre permissões de acesso, não sobre bloqueio. A segunda é um overhead enorme para uma verificação simples. A maneira real e testada por anos é tentar abrir o arquivo com acesso exclusivo. Se conseguir, o arquivo é seu. Se não, está ocupado.

Método nº1: Tentativa clássica de abertura (Try-Catch)

Esta é a abordagem mais simples e compreensível. Tentamos abrir o arquivo usando FileStream no modo FileShare.None. Se o arquivo estiver ocupado, uma IOException é lançada. Nós a capturamos e tiramos conclusões.

public static bool IsFileInUse(string filePath){    try    {        using (FileStream stream = File.Open(filePath, FileMode.Open, FileAccess.Read, FileShare.None))        {            // Arquivo aberto com sucesso, ninguém o está bloqueando            return false;        }    }    catch (IOException)    {        // Arquivo indisponível — provavelmente ocupado        return true;    }    catch (UnauthorizedAccessException)    {        // Sem permissão de leitura — também consideramos o arquivo "ocupado"        return true;    }}

Como usar isso? Muito simples:

string path = @"C:\\temp\\important.docx";if (IsFileInUse(path)){    Console.WriteLine("Arquivo ocupado. Tente fechá-lo em outros programas.");}else{    Console.WriteLine("Arquivo livre! Pode trabalhar.");}

Vantagens do método: concisão, clareza, funciona em todas as versões do .NET. Desvantagens: você ainda lança uma exceção a cada chamada, o que pode ser lento em verificações em massa. Mas para 90% das tarefas, isso é mais que suficiente.

Nuance importante: o que fazer se o arquivo estiver ocupado?

O cenário mais comum é você tentar gravar dados em um arquivo que já está aberto pelo usuário. Neste caso, não basta apenas dizer "ocupado". É necessário esperar ou sugerir que o usuário feche o arquivo. Aqui está um exemplo com espera:

public static bool WaitForFile(string filePath, int timeoutMs = 5000){    var sw = System.Diagnostics.Stopwatch.StartNew();    while (sw.ElapsedMilliseconds < timeoutMs)    {        if (!IsFileInUse(filePath))            return true;        Thread.Sleep(200); // pausa de 200 ms    }    return false; // não esperou o suficiente}

Este padrão é frequentemente usado em aplicações de servidor, quando é necessário aguardar