Remoção atômica do diretório

Question

Como rename(2)é chamado por mv, é seguro assumir que o seguinte seria atômico?

$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted

Answer 1

Omvcomandochama orenamechamada de sistema, que é garantido ser atômico. No entanto, existem duas exceções:

• Se a origem e o destino estiverem em sistemas de arquivos diferentes, o que é relativamente comum para /homevs. /tmp, então renamefalha e mvfunciona copiando a árvore de origem para o destino e removendo a árvore de origem. Evidentemente, isso não é atômico.
• Existem sistemas de arquivos onde renamenão é atômico, como certas implementações de NFS. Em qualquer sistema de arquivos local “normal”, renameé atômico.

Answer 2

Se os diretórios estiverem na mesma partição de hardware montada como um único sistema de arquivos, então mover algo é na verdade apenas renomeá-lo para um caminho diferente. No entanto, se não forem, então cada arquivo contido pode precisar ser lido e copiado, portanto, nenhuma parte da movimentação seria atômica. Como aponta Gilles, o POSIX estipula que este é o caso para sistemas de arquivos discretos.

Exceto isso, uma verificação rápida com straceconfirms mvusa a rename()chamada do sistema (não deve ser confundida com renameo utilitário de linha de comando). Isso tornaria mvum diretório atômico do ponto de vista do espaço do usuário. A rename()chamada do sistema gerará um erro EBUSY se:

oldpath ou newpath é um diretório que está em uso por algum processo (talvez como diretório de trabalho atual, ou como diretório raiz, ou porque estava aberto para leitura) ou está em uso pelo sistema (por exemplo, como ponto de montagem), enquanto o sistema considera isso um erro. (Observe que não há exigência de retornar EBUSY em tais casos - não há nada de errado em renomear de qualquer maneira - mas é permitido retornar EBUSY se o sistema não puder lidar com tais situações de outra forma.)

De man 2 rename. A conexão com a "atomicidade" aqui é que você não pode interromper outro processo trabalhando no diretório, e outro processo não pode interromper isso - ele terminará com um erro de caminho inválido/tipo não encontrado se você vencê-lo. a caçada.

Answer 3

Ambas as respostas dizem essencialmente a mesma coisa, mas focam apenas em um aspecto da remoção.

Se você tiver um shell cujo diretório de trabalho esteja dentro da árvore de diretórios renomeada/movida, ele continuará avereusaresses arquivos até que eles sejam realmente removidos. Por causa disso, o shell verá os arquivos em vários estados de exclusão e, conseqüentemente, a renomeação/movimentação (enquanto poderiaser"atômico"em si) énãouma forma atômica de exclusão do ponto de vista de todos os usuários dos arquivos. Afeta apenas usuários cujo shell está fora da árvore de diretórios desde o início.

O shell mantém suas próprias informações sobre o diretório em que está. Isso ocorre porque em algumas configurações você pode alterar o diretório atual para um onde não tenha permissão para ler a cadeia de informações do diretório necessárias para determinar o caminho real, por exemplo, seguindo um link simbólico para um diretório protegido.

O POSIX é vago quanto ao motivo do comportamento, mas aponta o comportamento parapwd(shell integrado) ecd(concha integrada).