Java bloqueio de arquivos e Windows - o bloqueio não é "absoluto"?

votos
4

Estou tentando bloquear um arquivo com Java no ambiente Windows com FileLock e eu tenho um problema: depois de bloquear o arquivo ainda pode ser acessado por outros processos, pelo menos em algum nível.

Exemplo código seguinte:

public class SimpleLockExample {
    public static void main(String[] args) throws Exception {
        String filename = loremlipsum.txt;

        File file = new File(filename);
        RandomAccessFile raf = new RandomAccessFile(file, rw);
        FileChannel channel = raf.getChannel();

        FileLock lock = null;
        try {
            lock = channel.tryLock();
            String firstLine = raf.readLine();
            System.out.println(First line of file :  + firstLine);
            waitForEnter();
            lock.release();
        } catch (OverlappingFileLockException e) {
            e.printStackTrace();
        }

        lock.release();
        System.out.println(Lock released);

        channel.close();
    }

    private static void waitForEnter() throws Exception {
        BufferedReader reader =
                new BufferedReader(new InputStreamReader(System.in));
        reader.readLine();
        reader.close();
    }
}

Agora, quando eu bloquear o meu arquivo com este exemplo, ele está bloqueado:

  • Ele não pode ser excluído pelo Windows
  • Eclipse se recusa a abrir

... mas não é ainda totalmente à prova de balas:

  • Se eu abri-lo com Scite (um editor de texto), por exemplo, nenhum conteúdo é mostrado, mas se eu optar por salvar o arquivo (Vazio como aberto ou com algum conteúdo escrito), ele consegue e o conteúdo do arquivo é apagado .. . (nenhum conteúdo existe lá depois, mesmo se eu tivesse escrito algo com Scite)

Existe alguma maneira de impedir que o arquivo totalmente de serem substituídos / apuradas por outros processos com Java no Windows?

Se eu entendi bem, estou usando atm bloqueio exclusivo. Com bloqueio compartilhado há ainda mais coisas que podem ser feitas.

Este teste foi executado com Windows 2000.

br, Touko

Publicado 27/08/2009 em 07:58
fonte usuário
Em outras línguas...                            


2 respostas

votos
4

Tricky, o próprio API FileLock não promete muito:

Este API de bloqueio de arquivo é destinado para mapear diretamente para o dispositivo de travamento nativa do sistema operacional subjacente. Assim, os bloqueios mantidos em um arquivo deve ser visível para todos os programas que têm acesso ao arquivo, independentemente do idioma em que esses programas são escritos.

Seja ou não um bloqueio impede realmente outro programa de acesso ao conteúdo da região bloqueada é dependente do sistema e, portanto, não especificado. As instalações de alguns sistemas de bloqueio de arquivo nativos são meramente consultivo, o que significa que os programas devem cooperativamente observar um protocolo de bloqueio conhecidos, a fim de garantir a integridade dos dados. Em outros sistemas bloqueios de arquivos nativos são de preenchimento obrigatório, o que significa que se um programa bloqueia uma região de um arquivo, em seguida, outros programas são realmente impedido de acessar essa região de uma forma que possa violar a fechadura. Em ainda outros sistemas, se os bloqueios de arquivos nativos são consultivo ou obrigatório é configurável em uma base per-file. Para garantir um comportamento consistente e correta em todas as plataformas,

Curiosamente, a discussão sobre o arquivo API bloqueio quando ele estava em desenvolvimento afirmaram que o Windows OS fornecido obrigatória bloqueio e no Unix única bloqueio consultivo. Então, em que a leitura se poderia esperar seu código para funcionar muito bem no Windows.

Pergunto-me se o que está acontecendo que seu editor não é tanto a modificação do arquivo como a criação de um arquivo temporário e, em seguida, manipular entradas de diretório, a fim de replce a versão do arquivo que você tiver bloqueado com uma nova versão. Será que o Windows permitir tal comportamento?

Gostaria de saber se você vai precisar de recorrer a JNI a fim de obter o nível de controle que você precisa.

Respondeu 27/08/2009 em 08:18
fonte usuário

votos
1

A sua chamada para .tryLock () pode retornar nulo se não obter o bloqueio. Desde o Javadoc:

Um objeto de bloqueio que representa o bloqueio recém-adquirida, ou nulo, se o bloqueio não pode ser adquirida porque outro programa mantém um bloqueio sobreposição

Além disso, o código atualmente abre o arquivo e, em seguida, ele tenta adquirir um bloqueio. Em vez disso você deve ciclo tentando obter o bloqueio, e uma vez que você tem isso, abra o arquivo, ler o arquivo, feche o arquivo, em seguida, dar-se o bloqueio. E dar-se o bloqueio em uma finally {}cláusula, apenas no caso de seu código lança uma exceção com o bloqueio mantido. (Já tive que reiniciar uma máquina Windows só porque algum arquivo foi bloqueado?)

Respondeu 23/03/2010 em 17:38
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more