FileSystemWatcher x sondagem para observar alterações no arquivo

Preciso configurar um aplicativo que observe os arquivos sendo criados em um diretório, localmente ou em uma unidade de rede.

Será que a FileSystemWatcherpesquisa ou em um timer seria a melhor opção. Eu usei os dois métodos no passado, mas não extensivamente.

Quais problemas (desempenho, confiabilidade etc.) existem em ambos os métodos?

Vi o observador do sistema de arquivos falhar nos ambientes de produção e teste. Agora considero uma conveniência, mas não a considero confiável. Meu padrão é observar alterações no observador do sistema de arquivos, mas sondar ocasionalmente para detectar alterações ausentes nos arquivos.

Editar: se você tiver uma interface do usuário, também poderá dar ao usuário a capacidade de "atualizar" as alterações em vez de pesquisar. Eu combinaria isso com um observador do sistema de arquivos.

O maior problema que tive foi a falta de arquivos quando o buffer ficou cheio. Fácil de corrigir, basta aumentar o buffer. Lembre-se de que ele contém os nomes e eventos dos arquivos, então aumente para a quantidade esperada de arquivos (tentativa e erro). Ele usa memória que não pode ser paginada e, portanto, pode forçar outros processos a paginar se a memória ficar baixa.

Aqui está o artigo do MSDN sobre o buffer: FileSystemWatcher .. ::. InternalBufferSize Property

Por MSDN:

Aumentar o tamanho do buffer é caro, pois vem da memória não paginada que não pode ser trocada para o disco, portanto, mantenha o buffer o menor possível. Para evitar um estouro de buffer, use as propriedades NotifyFilter e IncludeSubdirectories para filtrar as notificações de alteração indesejadas.

Usamos 16 MB devido a um grande lote esperado ao mesmo tempo. Funciona bem e nunca perde um arquivo.

Também lemos todos os arquivos antes de começar a processar um único ... obtemos os nomes dos arquivos armazenados em cache com segurança (no nosso caso, em uma tabela de banco de dados) e depois os processamos.

Para problemas de bloqueio de arquivos, inicio um processo que aguarda o desbloqueio do arquivo, aguardando um segundo, depois dois, depois quatro, etc. Nós nunca votamos. Isso está em produção sem erros há cerca de dois anos.

o FileSystemWatcher pode perder alterações durante os horários de pico, se o número de alterações na fila exceder o buffer fornecido. Isso não é uma limitação da classe .NET em si, mas da infraestrutura subjacente do Win32. Em nossa experiência, a melhor maneira de minimizar esse problema é desenfileirar as notificações o mais rápido possível e lidar com elas em outro encadeamento.

Conforme mencionado por @ChillTemp acima, o observador pode não funcionar em compartilhamentos que não são do Windows. Por exemplo, ele não funcionará em todas as unidades Novell montadas.

Concordo que um bom compromisso é fazer uma pesquisa ocasional para captar as alterações perdidas.

Observe também que o observador do sistema de arquivos não é confiável em compartilhamentos de arquivos. Especialmente se o compartilhamento de arquivos estiver hospedado em um servidor não Windows. O FSW não deve ser usado para nada crítico. Ou deve ser usado com uma pesquisa ocasional para verificar se não perdeu nada.

Pessoalmente, usei o FileSystemWatchersistema de produção e funcionou bem. Nos últimos 6 meses, ele não teve um único soluço executando 24x7. Ele está monitorando uma única pasta local (que é compartilhada). Temos um número relativamente pequeno de operações de arquivo com as quais ele deve lidar (10 eventos disparados por dia). Não é algo que eu já tive que me preocupar. Eu o usaria novamente se tivesse que refazer a decisão.

Atualmente, uso o FileSystemWatcherarquivo XML em atualização em média a cada 100 milissegundos.

Descobri que, enquanto o FileSystemWatcherestiver configurado corretamente, você nunca deverá ter problemas com arquivos locais .

Não tenho experiência em observação remota de arquivos e compartilhamentos que não são do Windows.

Considero que a pesquisa do arquivo é redundante e não vale a pena a sobrecarga, a menos que você confie inerentemente FileSystemWatcherou tenha experimentado diretamente as limitações que todos os outros aqui listaram (compartilhamentos que não são do Windows e observação remota de arquivos).

Eu iria com a votação.

Problemas de rede fazem FileSystemWatchercom que isso não seja confiável (mesmo ao sobrecarregar o evento de erro).

Ocorreu um problema ao usar FileSystemWatchercompartilhamentos de rede. Se você estiver em um ambiente Windows puro, pode não ser um problema, mas eu estava assistindo a um compartilhamento NFS e, como o NFS é sem estado, nunca houve uma notificação quando o arquivo que eu estava assistindo foi alterado.

Tive alguns problemas com o FSW em unidades de rede: a exclusão de um arquivo sempre gerava o evento de erro, nunca o evento excluído. Como não encontrei uma solução, agora evito o FSW e uso a pesquisa.

Por outro lado, os eventos de criação funcionaram bem; portanto, se você precisar apenas observar a criação do arquivo, poderá ir para o FSW.

Além disso, não tive problemas nas pastas locais, independentemente de serem compartilhadas ou não.

Retornando do método de evento o mais rápido possível, usando outro encadeamento, resolvi o problema para mim:

private void Watcher_Created(object sender, FileSystemEventArgs e)
{
    Task.Run(() => MySubmit(e.FullPath));
}

Usar o FSW e a pesquisa é um desperdício de tempo e recursos, na minha opinião, e estou surpreso que desenvolvedores experientes o sugiram. Se você precisar usar a pesquisa para verificar qualquer "falha no FSW", naturalmente poderá descartar o FSW completamente e usar apenas a pesquisa.

Atualmente, estou tentando decidir se usarei o FSW ou pesquisarei um projeto que desenvolvo. Lendo as respostas, é óbvio que há casos em que o FSW cobre perfeitamente as necessidades, enquanto outras vezes você precisa pesquisar. Infelizmente, nenhuma resposta realmente lidou com a diferença de desempenho (se houver), apenas com os problemas de "confiabilidade". Existe alguém que possa responder a essa parte da pergunta?

EDIT: o ponto de nmclean para a validade do uso do FSW e da pesquisa (você pode ler a discussão nos comentários, se estiver interessado) parece ser uma explicação muito racional por que pode haver situações em que o uso do FSW e da pesquisa é eficiente. Obrigado por esclarecer isso para mim (e para qualquer pessoa que tenha a mesma opinião), nmclean .

Solução de trabalho para trabalhar com criar evento em vez de alterar

Mesmo para copiar, cortar, colar, mover.

class Program
{        

        static void Main(string[] args)
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";
            FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
            FileSystemWatcher.Path = SourceFolderPath;
            FileSystemWatcher.IncludeSubdirectories = false;
            FileSystemWatcher.NotifyFilter = NotifyFilters.FileName;   // ON FILE NAME FILTER       
            FileSystemWatcher.Filter = "*.txt";         
             FileSystemWatcher.Created +=FileSystemWatcher_Created; // TRIGGERED ONLY FOR FILE GOT CREATED  BY COPY, CUT PASTE, MOVE  
            FileSystemWatcher.EnableRaisingEvents = true;

            Console.Read();
        }     

        static void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
        {           
                string SourceFolderPath = "D:\\SourcePath";
                string DestinationFolderPath = "D:\\DestinationPath";

                try
                {
                    // DO SOMETING LIKE MOVE, COPY, ETC
                    File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
                }
                catch
                {
                }          
        }
}

Solução para esse observador de arquivos enquanto o evento de alteração de atributo do arquivo usando armazenamento estático

class Program
{
    static string IsSameFile = string.Empty;  // USE STATIC FOR TRACKING

    static void Main(string[] args)
    {
         string SourceFolderPath = "D:\\SourcePath";
        string DestinationFolderPath = "D:\\DestinationPath";
        FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
        FileSystemWatcher.Path = SourceFolderPath;
        FileSystemWatcher.IncludeSubdirectories = false;
        FileSystemWatcher.NotifyFilter = NotifyFilters.LastWrite;          
        FileSystemWatcher.Filter = "*.txt";         
        FileSystemWatcher.Changed += FileSystemWatcher_Changed;
        FileSystemWatcher.EnableRaisingEvents = true;

        Console.Read();
    }     

    static void FileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
    {
        if (e.Name == IsSameFile)  //SKIPS ON MULTIPLE TRIGGERS
        {
            return;
        }
        else
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";

            try
            {
                // DO SOMETING LIKE MOVE, COPY, ETC
                File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
            }
            catch
            {
            }
        }
        IsSameFile = e.Name;
    }
}

Esta é uma solução alternativa para esse problema de múltiplos eventos de disparo.

Eu diria que use polling, especialmente em um cenário TDD, pois é muito mais fácil zombar / stub a presença de arquivos ou quando o evento de polling for acionado do que confiar no evento fsw mais "não controlado". + por ter trabalhado em vários aplicativos afetados por erros de fsw.