Por que não posso alterar arquivos em uso no Windows como eu posso no Linux e OS X?

Quando você estiver usando o Linux e o OS X, o sistema operacional não impedirá que você exclua um arquivo em uso no momento, ainda que no Windows você seja expressamente impedido de fazê-lo. O que da? Por que você pode editar e excluir arquivos em uso em sistemas derivados do Unix, mas não no Windows??

A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade..

A questão

O SuperUser reader the.midget quer saber por que o Linux e o Windows tratam os arquivos em uso de maneira diferente:

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 tudo em um arquivo sem se importar se está sendo usado no momento ou não.

Então, o que está acontecendo nos bastidores e impedindo-o de deletar coisas no Windows como ele pode no Linux??

A resposta

Os colaboradores do SuperUser lançam alguma luz sobre a situação da the.midget. Espantado escreve:

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 seja efetivado.

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á existindo no disco, desde que algum processo tenha um identificador aberto para ele, mesmo que sua entrada na tabela de arquivos tenha desaparecido.

David Schwartz expande a ideia e destaca como as coisas devem ser idealmente e como elas são na prática:

O padrão do Windows é 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.

Um monte de código antigo do Windows usa 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, uma abertura que permita uma operação conflitante será recusada, mesmo que o código nunca pretenda executar a operação conflitante, mas esteja apenas abrindo o arquivo para outra finalidade.

Então, 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 todas as operações possíveis poderia executar nele uma vez aberto é não-fluído.

Na minha opinião, o método do 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 básica do C / C ++ 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.

Lá você tem: duas abordagens diferentes para lidar com arquivos geram dois resultados diferentes.

Tem algo a acrescentar à explicação? Soe fora nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.