Por que não consigo alterar o nome de um arquivo que está sendo lido no Windows, como posso fazer no Linux / Mac?

Question

Uma das coisas que me intrigam desde que comecei a usar o Linux é o fato de permitir que você altere o nome de um arquivo ou até mesmo o exclua enquanto ele está sendo lido. Um exemplo é como eu acidentalmente tentei excluir um vídeo enquanto ele estava sendo reproduzido. Eu consegui, e fiquei surpreso quando soube que você pode mudar praticamente qualquer coisa em um arquivo sem se importar se está sendo usado no momento ou não.

    

Answer 1

Sempre que você abre ou executa um arquivo no Windows, o Windows bloqueia o arquivo (isso é uma simplificação, mas geralmente é verdade). Um arquivo bloqueado por um processo não pode ser excluído até que o processo seja liberado. É por isso que sempre que o Windows precisa se atualizar, você precisa de uma reinicialização para que ele tenha efeito.

Por outro lado, sistemas operacionais semelhantes ao Unix, como Linux e Mac OS X, não bloqueiam o arquivo, mas sim os setores de disco subjacentes. Isso pode parecer uma diferenciação trivial, mas significa que o registro do arquivo no índice do sistema de arquivos pode ser excluído sem perturbar qualquer programa que já tenha o arquivo aberto. Assim, você pode excluir um arquivo enquanto ele ainda está em execução ou em uso e continuará a existir no disco, desde que algum processo tenha um identificador aberto para ele, mesmo que sua entrada na tabela de arquivos tenha desaparecido.

    

Answer 2

O Windows é padronizado para o bloqueio automático e obrigatório de arquivos. O padrão do UNIX é o bloqueio manual e cooperativo de arquivos. Em ambos os casos, os padrões podem ser anulados, mas em ambos os casos eles geralmente não são.

Muitos códigos antigos do Windows usam a API C / C ++ (funções como fopen ) em vez da API nativa (funções como CreateFile ). A API C / C ++ não oferece nenhuma maneira de especificar como o bloqueio obrigatório funcionará, portanto, você obtém os padrões. O "modo de compartilhamento" padrão tende a proibir operações "conflitantes". Se você abrir um arquivo para escrever, as gravações serão consideradas conflitantes, mesmo se você nunca realmente gravar no arquivo. Idem para renomear.

E aqui é onde fica pior. Além de abrir para leitura ou gravação, a API C / C ++ não fornece nenhuma maneira de especificar o que você pretende fazer com o arquivo. Então a API tem que assumir que você vai realizar qualquer operação legal. Como o bloqueio é obrigatório, um open que permite uma operação conflitante será recusado, mesmo que o código nunca pretenda executar a operação conflitante, mas esteja apenas abrindo o arquivo para outra finalidade.

Portanto, se o código usa a API C / C ++ ou usa a API nativa sem pensar especificamente sobre esses problemas, eles acabam impedindo o conjunto máximo de operações possíveis para cada arquivo aberto e sendo incapazes de abrir um arquivo, a menos que a operação possível que eles poderiam realizar nele, uma vez aberta, não é afetada.

Na minha opinião, o método Windows funcionaria muito melhor do que o método UNIX se cada programa escolhesse seus modos de compartilhamento e abrisse os modos de casos de falha com cuidado e de forma sábia. O método UNIX, no entanto, funciona melhor se o código não se incomodar em pensar sobre esses problemas. Infelizmente, a API C / C ++ básica não é bem mapeada na API de arquivos do Windows de uma maneira que lida bem com os modos de compartilhamento e as janelas conflitantes. Então, o resultado líquido é um pouco confuso.

    

Answer 3

Essa é uma pergunta muito interessante e me fez pensar em uma resposta viável. Espero que outros possam fornecer backup aqui.

Eu uso o Windows e o Linux e notei isso também. Eu também sou um usuário do vim. O Vim lerá um arquivo de texto em um 'buffer', ou a RAM, e então não tocará no arquivo real até que você salve. O Linux pode estar executando esse tipo de ação em geral com todos os arquivos.

Pegue o seu vídeo, por exemplo, ele lê o vídeo, tudo isso, se possível, na RAM, e então você tem uma cópia do vídeo que é facilmente acessível, pesquisável, pulável. Se o arquivo for muito grande, você poderá ter problemas porque o Linux pode não ler o vídeo inteiro, talvez apenas um grande pedaço. Quando o jogador chegar ao final do vídeo em buffer, ele tentará ler o arquivo novamente. Se você apagou o vídeo, então isso é uma droga para você.

O Windows é um SO muito mais seguro em alguns casos, porque não permite que você faça isso. Ele pode armazenar em buffer os arquivos da mesma forma que o Linux, mas também adiciona o bloqueio de arquivos para impedir que você ou outros programas alterem os arquivos em que você está trabalhando ou visualiza. Isso ajuda a manter o arquivo intacto e impede que você ou outros programas sobrescrevam as alterações uns dos outros.