17Aug
Quando você estiver usando Linux e OS X, o sistema operacional não o impedirá de excluir um arquivo atualmente em uso no Windows, você estará expressamente impedido de fazê-lo. O que da? Por que você pode editar e excluir arquivos em uso em sistemas derivados de Unix, mas não no Windows?
Today's Question &A sessão de atendimento chega a cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento comunitário de sites Q & A.
A Pergunta
Leitor SuperUser the.midget quer saber por que o Linux e o Windows tratam os arquivos em uso de forma diferente:
Uma das coisas que me perplexo desde que comecei a usar o Linux é o fato de que ele permite que você altere o nome deum arquivo ou mesmo excluí-lo enquanto ele está sendo lido. Um exemplo é como tentei, de forma acidental, excluir um vídeo enquanto estava sendo reproduzido. Eu consegui e fiquei surpreso ao saber que você pode mudar praticamente qualquer coisa em um arquivo sem se preocupar se está sendo usado no momento ou não.
Então, o que está acontecendo nos bastidores e impedindo ele de excluir as coisas no Windows como ele pode no Linux?
A resposta Os contribuidores
SuperUser lançam alguma luz sobre a situação do. midget. Amazed escreve:
Sempre que você abre ou executa um arquivo no Windows, o Windows bloqueia o arquivo no local( isto é uma simplificação, mas geralmente é verdade.) Um arquivo bloqueado por um processo não pode ser excluído até que esse processo o libere.É por isso que sempre que o Windows precisa se atualizar, você precisa de uma reinicialização para que ele entre em vigor.
Por outro lado, os sistemas operacionais semelhantes a 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 isso significa que o registro do arquivo na tabela de conteúdo do sistema de arquivos pode ser excluído sem perturbar qualquer programa que já tenha o arquivo aberto. Então, você pode excluir um arquivo enquanto ele ainda está sendo executado ou de qualquer outra forma em uso e ele continuará a existir no disco, desde que algum processo tenha um identificador aberto, mesmo que sua entrada na tabela de arquivos tenha desaparecido.
David Schwartz expande a idéia e destaca como as coisas devem ser ideais e como elas estão na prática:
O Windows padrão é o bloqueio de arquivos automático e obrigatório. UNIXes padrão para manual, bloqueio de arquivo cooperativo. Em ambos os casos, os padrões podem ser superados, mas em ambos os casos eles geralmente não são.
Um monte de código Windows antigo 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á, para que você obtenha os padrões. O "modo de compartilhamento" padrão tende a proibir operações "conflitantes".Se você abrir um arquivo para escrever, as escrituras são assumidas como conflitantes, mesmo que você nunca escreva no arquivo. Ditto para renomear.
E, aqui é onde fica pior. Além de abrir para ler ou escrever, a API C / C ++ não fornece nenhuma maneira de especificar o que você pretende fazer com o arquivo. Portanto, a API deve assumir que você irá realizar qualquer operação legal. Uma vez que o bloqueio é obrigatório, um aberto que permite uma operação conflitante será recusado, mesmo que o código nunca pretendesse executar a operação conflitante, mas estava 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 acabarão impedindo o conjunto máximo de operações possíveis para cada arquivo que abre e não pode abrir um arquivo, a menos que todas as operações possíveiseles poderiam executar nele uma vez aberto não é violado.
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 modos abertos de forma inteligente e sanamente tratados casos de falha. O método UNIX, no entanto, funciona melhor se o código não se preocupar em pensar nessas questões. Infelizmente, a API C / C ++ básica não mapeia bem na API do arquivo do Windows de uma maneira que manipula modos compartilhados e conflitos abre bem. Então, o resultado líquido é um pouco confuso.
Lá você tem: duas abordagens diferentes para o processamento de arquivos produzem dois resultados diferentes.
Tem alguma coisa a adicionar à explicação? Som na parte dos comentários. Deseja ler mais respostas de outros usuários Tech-savvy Stack Exchange? Confira o tópico de discussão completo aqui.
