Pergunta

É possível abrir um arquivo de texto e ler o conteúdo, enquanto outro aplicativo está atualizando o arquivo, de tal forma que ele não causar um conflito de bloqueio?

Eu preciso para monitorar um arquivo de log de um aplicativo que é atualizado por outra aplicação cada vez que ocorre um evento.

Eu faço verificação se o arquivo está em uso antes de tentar lê-lo, mas que não parecem funcionar em todos os casos.

Obrigado, Pieter

Foi útil?

Solução

depende de como o primeiro aplicativo abrir esse arquivo.

ou seja ao chamar CreateFile API para abrir um arquivo, há dwShareMode param que conta a api como abri-lo (se este foi dado 0, ele não pode ser acessado a partir de outras aplicações IIRC). caso contrário, não deve haver nenhum problema com a leitura desse arquivo. se im não sejam confundidos, para verificar se o arquivo está sendo aberto somente leitura u pode chamar algo como

CreateFile(pchar(fName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0) ;

Outras dicas

  1. Baixar Process Monitor da Sysinternals.
  2. Abra o diálogo de filtro e adicione um filtro de "caminho" para o seu arquivo de log.
  3. Inicie a aplicação de gravação de log (vou chamar isso de "logWriter").
  4. Procure e clique no evento onde logWriter faz um CreateFile.
  5. Em "Detail", ele deve ter "acesso desejado: Write genérico". E ele deve ter "ShareMode: Ler", o que corresponde a FILE_SHARE_READ na chamada para CreateFile. O que significa é: "Eu, logWriter, permitir que outros ler meu arquivo".
  6. Agora execute seu aplicativo de leitura de log ( "logreader"), e fazer o mesmo exercício.
  7. O detalhe deveria ter "desejado Acesso: Leitura genérica". E ele deve ter "ShareMode: ler, escrever"., Que significa, "Eu, logreader, permitir que outros, incluindo logWriter, a ler e escrever no arquivo de log"

Esses são os valores mais sensata, eu acho, e eles vão evitar bloqueio. Outras combinações podem ser permitidas. Há é uma mesa aqui .

Agora, você não disse o que acontece quando "não parece trabalho em todos os casos". O que fazer em seguida dependerá realmente os detalhes. Esperemos que o acima lhe dará informação suficiente para descobrir o que está acontecendo de errado.

Você não terá um conflito de bloqueio porque a aplicação escrita é muito pouco provável que tenha bloqueado o arquivo. Fazendo o que você sugere geralmente funciona sem problemas (é o que o UNIX -f comando cauda faz) e essas pequenas falhas que ocorrem podem ser ignorados. Eu escrevi um par de aplicativos de monitoramento de log in te passado que funcionava assim, sem problemas.

Tente usar FileSystemWatcher para obter eventos quando um arquivo é atualizado.

A mais delphi amigáveis ??

Para além de conseguir o compartilhamento de arquivos para a direita trabalho que pode ser impossível dependendo do que os outros pedidos de programas, alguns programas vão fechar o arquivo entre acessos.

Tenho tido sucesso no passado com o meu programa de espera para o arquivo para se tornar disponível, em seguida, rapidamente abri-lo, agarrando os dados necessários e fechá-lo. Pelo menos em DOS uma tentativa de acessar um arquivo bloqueado causado algumas tentativas, e eu colidido até essa configuração, de modo que se o outro programa tentou para o arquivo enquanto eu tinha que eles simplesmente ser adiada e nunca ver um erro.

Eu ainda era capaz de atualizar o arquivo (tenho a certeza não para fechá-lo no meio!) Sem o outro programa nunca saber uma coisa.

feio como o pecado, mas não conseguimos mudar o outro programa para que ele era a única maneira de fazer o trabalho. Foi implantado em casa por anos, eu nunca ouvi um pio dos usuários do sistema. Ele finalmente foi embora quando a máquina a outro programa controlado foi aposentado.

XpoLog irá fazer o truque sem alterar o env ou código, monitor de log XpoLog

Avar é certo - você está à mercê do programa de escrita aqui. Se eles estão bloqueando o arquivo, em seguida, há um par de coisas que você pode fazer:

1 - Verifique se há um href="http://delphi.about.com/cs/adptips1999/a/bltip1199_4.htm" rel="nofollow mudança na "última modificação" tempo de data -. Se isso mudar, então você sabe algo que aconteceu

2 -. Se a data e hora da modificação fez a mudança, então (dependendo do tamanho do arquivo) pode ser bom o suficiente para criar uma cópia do arquivo e verificação que

nós usamos "cauda para win32",

Eu sei que não delphi, mas pode ser útil

http://tailforwin32.sourceforge.net/

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top