Caixa Seca

Quando escrevi sobre o driver ntfs3 ( 1 , 2 , 3 ), imaginei que haveria tração suficiente da comunidade para aprimorá-lo, com uma manutenção competente da Paragon. Não foi o que aconteceu. Quatro anos depois, o código funciona, mas está longe de alcançar a estabilidade necessária. Ainda não suporta a montagem de volumes NTFS sujos — aqueles não desmontados corretamente —, processo conhecido como journal replay , no qual o driver consulta o histórico de transações e refaz as operações incompletas (e ignora as não commitadas) para restaurar a atomicidade e a consistência do sistema de arquivos. Esse recurso foi prometido desde o início e, até hoje, está quebrado. Além disso, o código usa APIs obsoletas do kernel, que, embora suportadas, revelam uma manutenção precária. A Paragon também prometeu ferramentas para criação e, especialmente, verificação de volumes NTFS, mas não cumpriu. Agora, surge o anúncio do ntfsplus : https://lore.kernel.org/lkml/2025...

O instalador do Windows, em UEFI, sempre aproveita a partição EFI [1] existente, independente do disco em que resida, visto que deve ser única por máquina . Tê-la num disco diferente da instalação atual, remanescente de instalações anteriores, não é tão incomum. Remover ou apagar esse disco surpreende os não familiarizados ao impedir a inicialização. O que fazer quando a partição EFI não existe mais? Começamos iniciando a mídia de instalação e, nela, carregando o Windows RE, que é o ambiente de recuperação embutido. Os assistentes automatizados de nada ajudam nesta questão. Precisamos do Prompt de Comando: Reparar o computador → Solução de Problemas → Prompt de Comando. Primeiro passo é carregar o diskpart , identificar o disco da instalação a ser recuperada e selecioná-lo: diskpart list disk select disk X detail disk Substitua X pelo número que aparece na coluna "Nº Disco" de list disk . A saída de detail disk dará deta...

O Hyper-V tem um recurso interessante no comutador "Default Switch" que automaticamente adiciona um registro DNS no hospedeiro com o nome de máquina do convidado quando este obtém IPv4 via DHCP. É salvo em %SystemRoot%\System32\drivers\etc\hosts.ics e usa o domínio mshome.net . Meu convidado Fedora 40 não estava aparecendo lá. NetworkManager envia o nome de máquina na requisição DHCP: $ nmcli connection show eth0 | grep hostname ipv4.dhcp-send-hostname: sim [...] Descrição da propriedade no manual nm-settings : If TRUE, a hostname is sent to the DHCP server when acquiring a lease. Some DHCP servers use this hostname to update DNS databases, essentially providing a static hostname for the computer. If the "dhcp-hostname" property is NULL and this property is TRUE, the current persistent hostname of the computer is sent. Depois de quebrar um pouco a cabeça, lembrei que a instalação do Fedora por padrão não configura um nome ...

Há uma enorme confusão sobre esse assunto. Afinal, para instalar o Windows em UEFI, a mídia de instalação precisa estar particionada em GPT? BIOS UEFI [1] suportam particionamento MBR e GPT, enquanto BIOS antigos (não UEFI) apenas suportam MBR [2] . Tanto faz, portanto, com UEFI. Então por que muita gente acha que GPT é requerido? Presumo por dois motivos: → O Windows requer que o disco de destino, no qual será instalado, seja particionado em GPT. A exigência, contudo, não aplica-se à mídia de instalação. → O Rufus artificialmente restringe a criação de mídias compatíveis com UEFI ao particionamento GPT, ao contrário do Media Creation Tool (MCT) da Microsoft, que sempre particiona em MBR. Tal comportamento do Rufus tem como objetivo evitar confusão, pois discos em GPT não iniciam em máquinas com BIOS antigos. Assim, tem-se uma mídia UEFI-only . Já discos em MBR funcionam com BIOS antigos. Será que tais mídias iniciam também em UEFI...

No particionamento MBR, o BCD armazena o caminho para cada partição usando deslocamento e assinatura de disco (ver Como as partições são identificadas no BCD ). Clonando discos com o venerável Ghost, poderíamos assumir que, ao mover os inícios das partições (ao redimensioná-las), suas entradas ficariam inválidas. MBR Não é o caso, pois o programa é inteligente para automaticamente atualizar o BCD, tanto com o deslocamento, quanto com a nova assinatura de disco. Por padrão, uma nova assinatura é criada no destino nos modos disco para disco e imagem para disco . Com GPT, novos GUIDs são gerados, para o disco e partições — BCD é atualizado de acordo igualmente. Podemos alterar esse comportamento com -fdsp , que mantém a assinatura original em MBR (deslocamentos são atualizados no BCD mesmo assim) e, em GPT, preserva todos os GUIDs, de modo que o BCD não precisa ser alterado. Ter mais de um disco co...

Dias atrás, surgiu no fórum Clube do Hardware a dúvida se, ao mover partições do Windows, entradas para as mesmas no BCD — banco de dados onde ficam armazenadas as configurações do carregador de inicialização desde o Vista — deixariam de funcionar, requerendo reconfiguração ( BootRec /RebuildBcd do Windows RE é o jeito mais simples). Tal assunto está bem documentado aqui . O que bcdedit /enum ALL mostra em device , osdevice , filedevice e ramdisksdidevice é a tradução que o programa faz, com intuito de deixar a saída amigável. Por baixo do capô, assinatura NT do disco e o deslocamento em bytes estão salvos caso seja MBR; em GPT, os GUIDs do disco e da partição [1] . Isso quer dizer que, em GPT, as partições podem ser movidas à vontade, enquanto que, em MBR, seus inícios não podem ser alterados. Depois de publicar este texto, descobri a opção não documentada bcdedit /raw , que exibe o dispositivo sem firulas! [1] detail partition do...

A mídia de instalação do Windows 8 e superiores automaticamente detecta caso exista uma tabela ACPI MSDM no BIOS, contendo uma chave, e, quando presente, suprime a tela de escolha de versão (Home, Pro, etc). Há casos, entretanto, em que precisamos instalar uma versão diferente da que veio licenciada na máquina. Para isso, criamos um arquivo de texto plano com nome ei.cfg , dentro da pasta sources da mídia, contendo o seguinte: [Channel] _Default [VL] 0

O mantenedor do código apareceu. Patches fluindo lentamente. Kernel 5.19 trará algumas correções . Não havendo mais imprevistos , o processo de estabilização começa a partir dessa versão — alguns commits serão backportados para o 5.15 LTS, porém o desenvolvimento principal acontece na árvore mainline .

Quando postei Linux 5.15 contará com novo driver NTFS , esperava que, lançado o kernel 5.15 com o novo driver ntfs3 da Paragon Software, começasse o processo de correção de bugs logo em seguida, com a estabilidade continuamente melhorando a cada nova versão. Infelizmente, não foi o que aconteceu. Konstantin Komarov, mantenedor do código, desapareceu e, no repositório oficial, o último commit é de 12 de outubro de 2021. Desde que a versão 5.15 foi lançada, nenhuma mudança relevante foi aplicada — apenas adequações à API interna do kernel feitas por outros desenvolvedores. No repositório de desenvolvimento , há nove commits adicionais, sendo o último de 24 de novembro de 2021. Andei testando-o no Fedora nas últimas semanas (5.15.x até 5.16.8 enquanto escrevo). O desempenho é muito melhor do que o NTFS-3G, porém é instável. É fácil fazê-lo travar com o rsync (o kernel fica em pé pelo menos) e links simbólicos e pontos de junção não são resolvidos corretament...

Ao usar o Rufus com o UEFI:NTFS (quando há arquivo maior do que 4 GiB na mídia de instalação do Windows), era necessário desabilitar secure boot temporariamente para conseguir inicializar pelo pendrive. Não mais a partir do Rufus 3.17. Pete conseguiu fazer a Microsoft assinar o UEFI:NTFS e o driver EFI baseado no NTFS-3G . Portanto, agora funciona com secure boot sem reclamar. Como os binários são públicos, podemos aproveitá-los no processo manual, para Linux, comentado no post Pendrive de instalação do Windows a partir do Linux (II) . Atualizei-o, pois o tamanho da partição para acomodar a imagem aumentou de 512 KiB para 1 MiB. Ou seja, refaçam seus pendrives de instalação do Windows com o Rufus 3.17+!

O driver ntfs do Linux é um código deficiente, com suporte à escrita quebrado, e sem manutenção. Tanto que algumas distribuições desativam-no e fornecem apenas o lento NTFS-3G , que roda no espaço de usuário. Depois de um ano de discussão, o novo driver ntfs3 da Paragon foi aceito e estará disponível na versão 5.15. Suporta leitura e escrita, compressão, ACLs, arquivos esparsos, replay do journal — processo de colocar o sistema de arquivos num estado consistente caso não tenha sido desmontado corretamente da última vez. Como todo novo código, será azeitado nos próximos meses, com a Paragon se comprometendo em mantê-lo (lista de discussão aqui ). Considero um driver muito promissor e importante para uma melhor interoperabilidade com o Windows. Os ganhos no desempenho serão significativos e tendem a melhorar com o tempo. Junto com os drivers exfat , presente desde a versão 5.7 , e vfat , fará o kernel ter suporte de primeira aos sistemas de ...

Quanta diferença na minha reação ao Windows 11 (Insider) comparada ao Windows 10 lá em 2014. Naquela época, era uma novidade excitante, importante, pois estávamos com a interface horrenda do 8.1, que ninguém aguentava mais. Hoje, vejo o Windows 11 mais como uma oportunidade para a Microsoft subir a exigência de hardware — com bons propósitos no caso de Secure Boot e Trusted Platform Module —, removendo finalmente a versão x86-32 (e possivelmente suporte ao BIOS/CSM), do que qualquer outra coisa. Se o fizesse no ciclo de vida do Windows 10 arriscaria tomar processo na justiça por todos os lados. Mantendo o 10 rodando em cacarecos até 2025 resolve o problema.

No Windows 10 2009 (20H2), o arquivo sources\install.wim passou a ter mais de 4 GiB, o que impossibilita o uso de FAT32. Precisamos recorrer ao NTFS. Sem FAT32, contudo, perdemos a garantia de suporte via UEFI. A saída é o UEFI:NTFS , cujo propósito é ler sistemas de arquivos NTFS ou exFAT do disco em uso e carregar \EFI\BOOT\BOOT<arquitetura>.EFI . Criamos uma pequena partição de 1 MiB [1] , do tipo 0xEF , para abrigá-lo. Usamos a imagem FAT12 do Rufus ( uefi-ntfs.img ), que contém o UEFI:NTFS bem como drivers EFI para NTFS e exFAT . No espaço restante, uma única partição, ativa, do tipo 0x07 . # echo -e ',2048,EF\n,,07,*' | sfdisk --lock=yes --wipe=always --wipe-partitions=always --label=dos /dev/sdx # curl -Ls https://github.com/pbatard/rufus/raw/master/res/uefi/uefi-ntfs.img | dd conv=fsync,notrunc of=/dev/sdx1 Agora criamos o sistema de arquivos NTFS na segunda partição: # mkfs.ntfs -f /dev/sdx2 Caso o alvo seja UEFI, basta m...

Cenário: servidor Linux rodando Samba com clientes Windows. Quando acessamos, num grupo de trabalho, outra máquina na rede local pelo nome, digamos \\CENTOS , o Windows 10 tentará os seguintes protocolos para achá-la: NetBIOS, mDNS e LLMNR. 16:57:54.025570 IP 192.168.2.2.netbios-ns > 192.168.2.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:57:54.025651 IP 192.168.2.2.mdns > 224.0.0.251.mdns: 0 A (QM)? CENTOS.local. (30) 16:57:54.025725 IP6 fe80::f0a4:cbb5:c600:f448.mdns > ff02::fb.mdns: 0 A (QM)? CENTOS.local. (30) 16:57:54.025870 IP 192.168.2.2.mdns > 224.0.0.251.mdns: 0 AAAA (QM)? CENTOS.local. (30) 16:57:54.025929 IP6 fe80::f0a4:cbb5:c600:f448.mdns > ff02::fb.mdns: 0 AAAA (QM)? CENTOS.local. (30) 16:57:54.026235 IP6 fe80::f0a4:cbb5:c600:f448.51438 > ff02::1:3.hostmon: UDP, length 24 16:57:54.026301 IP 192.168.2.2.51438 > 224.0.0.252.hostmon: UDP, length 24 16:57:54.026464 IP6 fe80::f0a4:cbb5:c600:f448.64716 > ff02::1:3.hostmon: UD...

No Windows 10 1803, com objetivo de diminuir o uso de disco, a Microsoft desativou o backup automático do registro , salvo em %SYSTEMROOT%\system32\config\RegBack . Pode ser restaurado com facilidade sobrescrevendo os arquivos de mesmo nome uma pasta abaixo. Para quem tem espaço e poder de processamento sobrando, sugiro ativar novamente. É um backup que numa improvável eventualidade pode salvar a lavoura — particularmente o SYSTEM . Basta importar: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager] "EnablePeriodicBackup"=dword:00000001 Não consegui descobrir exatamente como funciona o agendamento. É feito uma vez a cada uma ou duas semanas mais ou menos.

Pergunta que de quando em quando aparece nos fóruns. Há ferramentas aos moldes do excelente Rufus para Linux, acho. Dá também para rodá-lo dentro de uma máquina virtual com Windows, conectando o dispositivo USB ao sistema operacional convidado. Tratarei aqui da forma manual, entretanto. Não é muito complicado. Precisamos de particionamento MBR (MS-DOS), que serve tanto para instalar em Legacy/CSM quanto UEFI, com uma partição formatada em FAT32. O particionamento é tranquilo. Pode ser feito via cfdisk , fdisk ou sfdisk , bem como parted ou GParted. A partição precisa ser marcada como ativa para funcionar no modo Legacy/CSM. Usando como exemplo /dev/sdx . Comandinho mágico : # echo ',,0c,*' | sfdisk --lock=yes --wipe=always --wipe-partitions=always --label=dos /dev/sdx (tipo 0x0c : FAT32 LBA) Depois criamos o sistema de arquivos FAT32: # mkfs.fat -F 32 -v /dev/sdx1 Caso o alvo seja UEFI, basta montar /dev/sdx1 e extrair o conteúdo do...

Tenho uma pasta na raiz da unidade C: onde coloco alguns programas úteis. Está presente na variável de ambiente PATH do sistema. As ACLs padrão da raiz da unidade dão permissão de escrita, em todas as pastas ali criadas — propagada ao conteúdo descendente —, a todos os usuários autenticados (que tenham feito logon), incluindo quem não é administrador. Diferente das pastas C:\Program Files e C:\Program Files (x86) , tipicamente usadas para tais fins, que não possuem permissão de escrita para usuários limitados. Por isso alguns programas burros, que não fazem diferenciação entre o território do sistema operacional e do usuário , criam pastas diretamente na unidade C: . Qualquer usuário autenticado pode escrever ali, não sendo necessário usar o perfil. Nosso maior exemplo são os programas da Receita Federal, cuja pasta é C:\Arquivos de Programas RFB . Contudo, como minha pasta está no PATH , é um problema! Pode ser usada para ataques de DLL preloading . É imperativo remover a per...

(ou: mais um motivo para deixar o Windows 7 💀 para trás) Quem lida com arquivos grandes acessando-os através de compartilhamentos de rede sofre com Windows anteriores ao 8/Server 2012 pela falta de suporte à requisição FSCTL_SRV_COPYCHUNK do protocolo SMB2 no Windows Explorer. Suponha que copiemos \\serv\pasta1\arq.7z para \\serv\pasta2 . No Windows 7, todo o conteúdo de arq.7z trafegará pela rede duas vezes: primeiro do servidor para o cliente (leitura), depois do cliente para o servidor (escrita). A partir do Windows 8, o cliente apenas diz ao servidor para copiar o arquivo de uma pasta para outra — a cópia é feita internamente no servidor, sem trafegar pela rede. Faz uma diferença enorme. Suportado a partir do Samba 4.1.0 sem necessidade de configuração adicional. Referências: Server-Side Copy (SambaWiki) Relacionado: Guia de configuração do Samba não-PDC

Para modelos corporativos a Dell oferece diferentes meios de atualização de BIOS. Servidores, por exemplo, têm como opção atualizadores que rodam sobre Windows x64 (modelos antigos ainda oferecem versão x86 adicionalmente), DOS e até Linux. Já as máquinas domésticas não desfrutam da mesma facilidade. Temos apenas o executável híbrido Windows x86 e DOS. Quando não usamos Windows — e a Dell oferece modelos com Ubuntu —, ter que mudar o modo de inicialização para carregar DOS é uma chatice. Além de que, a partir do ano que vem, os fabricantes começarão a extinguir o Compatibility Support Module (CSM) , seguindo os passos da Intel. Daí adeus DOS e Windows x86. É muito mais fácil carregar um Windows PE x64, que inicializa via UEFI/Secure Boot sem briga, e rodar lá. No entanto, nele, não existe o subsistema WOW64 , sendo impossível rodar executáveis x86. Desde 2017 , a Dell disponibiliza um atualizador genérico x64: Utilitário de Flash do BIOS da Dell de 64 bits (3.3.6, A04) S...

Melhor forma de saber, com precisão, o espaço usado em volumes NTFS: fsutil volume allocationreport X: (como Administrador, substituindo X pela unidade desejada) Suportado a partir do Windows 8.1. Explicação (Ntdebugging Blog): NTFS Misreports Free Space? Ntfs Misreporting Free Space (Part 2) NTFS Misreports Free Space (Part 3)