Porque é que a minha pen se tornou "apenas leitura" e (como) posso arranjá-la?

Tenho uma pen drive novinha em folha (com uma semana de idade) que ficou marcada apenas como lida, por Windows, Kubuntu e um divisor de arranque. Porque é que isto aconteceu? É fixável? Se é, como é que posso corrigir isto?

O problema

Primeiro, esta unidade é nova. Certamente não tem sido usado o suficiente para morrer de desgaste normal, embora eu não descontasse componentes defeituosos.

A própria unidade ficou de alguma forma bloqueada num estado apenas de leitura. Gestão do disco do Windows:

Generic Flash Disk USB Device
Disk ID: 33FA33FA
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : Yes
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No

Diskpart:

Warning: Only 7762 of 7812 MByte tested.
The media is likely to be defective.
7.5 GByte OK (15896472 sectors)
52 KByte DATA LOST (104 sectors)
Details:0 KByte overwritten (0 sectors)
0 KByte slightly changed (< 8 bit/sector, 0 sectors)
52 KByte corrupted (104 sectors)
0 KByte aliased memory (0 sectors)
First error at offset: 0x0000000186003000
Expected: 0x0000000186003000
Found: 0x00200800c40c3061
H2testw version 1.3
Writing speed: 3.95 MByte/s
Reading speed: 14.0 MByte/s
H2testw v1.4

O que realmente me confunde é Current Read-only State : Yes e Read-only : No.

Tentativa de soluções

Até agora, tenho tentado:

• Formatação em Windows (na gestão de discos, as opções de formato são cinzentas quando se clica com o botão direito do rato).

• DiskPart Clean (CLEAN - Clear the configuration information, or all information, off the disk.):

• Formato de linha de comando do Windows

• Windows chkdsk: ver abaixo para detalhes

• Kubuntu fsck (através do VirtualBox USB passthrough): ver abaixo para detalhes

• Acronis True Image para formatar, para converter para GPT, para destruir e reconstruir MBR, basicamente qualquer coisa: falhou (não conseguiu escrever para MBR)

Detalhes (e uma boa história)

Background

Esta era uma unidade flash novinha em folha, genérica, de 8GB com a qual eu queria criar uma unidade flash multiboot. Veio formatada como FAT32, embora estranhamente um pouco maior que a maioria das 8 unidades flash GIGAbyte com que me deparei. Aproximadamente 127MB foi listada como “usada” pelo Windows. Nunca descobri porquê. O espaço útil final era sobre o que normalmente espero de uma unidade de 8GB (aproximadamente 7,4 GIBIbytes).

Eu tinha atirado bastantes distros Linux, juntamente com uma cópia de Hiren’s. Todas elas arrancavam na perfeição. Foram colocadas com YUMI .

Quando tentei colocar o DVD do Knoppix, a YUMI adicionou uma opção de vídeo estranha ao seu comando de arranque que fez com que o Knoppix arrancasse com um ecrã preto no X. ttys 1 a 6 ainda funcionava como interfaces apenas de texto.

Alguns dias mais tarde, demorei algum tempo a tirar essa opção de vídeo ímpar, fazendo com que o comando de arranque coincidisse com o que vem com o Knoppix. Na tentativa de arranque, o Knoppix relatou alguma forma de corrupção LZMA.

levando à edição actual

Eu estava a pensar que os ficheiros do Knoppix podem ter sido corrompidos de alguma forma, por isso tentei recarregá-lo. A unidade estava quase cheia (45MB livre), por isso apaguei uma ISO genérica que também não estava a arrancar. Correu bem. Passei então pelo YUMI para ‘desinstalar’ o Knoppix, ou seja, apagar ficheiros e remover dos menus. Os ficheiros foram primeiro apagados, depois os menus foram apagados com sucesso. No entanto, o espaço livre ficou preso a cerca de 700MB, tal como estava antes de remover o Knoppix. Na antiga pasta Knoppix, havia um ficheiro de 0 bytes chamado KNOPPIX que não podia ser apagado.

Tentei reinserir a unidade para apagar este ficheiro - sem remover com segurança, se isso fizesse diferença (ei, primeira vez para tudo). Executando o Windows padrão chkdsk scan sem /r ou /f reportou erros encontrados. Executando com /r acabou de ficar bloqueado.

decidi dar fsck& uma tentativa, por isso carreguei o meu Kubuntu VM e anexei-lhe a unidade com a passagem USB 2.0 da VirtualBox. Eu umount& fiz (/dev/sda1) e corri um fsck. There are differences between boot sector and its backup. Escolhi No action. Disse-me que os FATs são diferentes e pediu-me para seleccionar o primeiro ou o segundo FAT. Qualquer que tenha seleccionado, recebi um aviso de Free cluster summary wrong. Se eu escolhesse Correct, daria uma lista de nomes de ficheiro incorrectos. Para tentar corrigir something, pelo menos, executei-o com a opção -p. A meio da correcção dos ficheiros, o VM congelou - terminei o seu processo cerca de dez minutos mais tarde.

Cause?

A minha próxima tentativa foi usar o YUMI, mais uma vez, para reconstruir todo o disco. Usei a opção YUMI construída em reformat (para FAT32) e instalei uma ISO Kubuntu (700MB). O formato foi bem sucedido, contudo, o extracto e cópia do Kubuntu (para o qual a YUMI usa um binário de 7zip) congelou a cerca de 60% feito. Depois de esperar cerca de quinze minutos (mais tempo do que o Knoppix ISO de 3,5GB levou na última vez), puxei o disco para fora. A unidade nesta altura já estava formatada, o SYSLINUX já estava instalado, apenas à espera de desempacotar uma ISO e de modificar os menus de arranque.

Voltando a ligá-lo, surgiu como normal - no entanto, qualquer acção de escrita falharia. A gestão do disco informou-o apenas como lido. Ao voltar a ligá-lo, a operação de escrita seria considerada normal, mas uma operação de escrita faria com que voltasse a ser lida apenas. Após algumas tentativas, começou a surgir como sendo apenas lido na inserção.

Tentativas de correcção

Isto é quando passei pelas tentativas listadas acima, para tentar reformatá-lo no caso de um formato defeituoso. Contudo, a incapacidade de o fazer, mesmo num disco de arranque, indica que algo mais grave está errado. chkdsk agora relata que nada está errado, e fsck ainda relata inconsistências MBR, mas agora escolhe sempre primeiro FAT automaticamente depois de me dizer que os FAT diferem. Continua a fazer o mesmo Free cluster summary wrong depois. Já não posso correr com o -p porque agora está marcado apenas como lido. Conseguiu também corromper de alguma forma o disco do meu VM na primeira tentativa (sim, tenho a certeza que escolhi sda, que é mapeada para uma unidade de 7,4GB - eu triple verifiquei). Graças a Deus por instantâneos?

Estou quase sem ideias. Para a minha mente inexperiente, parece que algo no firmware da unidade o configurou para ler apenas “permanentemente” de alguma forma - há alguma forma de reiniciar isto? Não me interessa particularmente manter os dados, tendo em conta que os reformatei duas vezes.

Além disso, as correcções que me mantêm no Windows são melhores; reduz o risco de eu acidentalmente destruir acidentalmente o meu disco rígido principal.

Actualização 1:

Desmontei a unidade por curiosidade.

Como se pode ver, não há interruptores óbvios de protecção de escrita. Há um CI do outro lado, com a marca ALCOR AU6989HL, se isso for importante. Se parecer não haver maneira de corrigir isto, provavelmente vou retirar o cartão (colado) e colocá-lo num leitor de cartões para verificar se foi o cartão ou o controlador que morreu.

Actualização 2:

Retirei o cartão, o Windows detecta agora a unidade como um leitor de cartões. Os contactos no cartão não parecem ser utilizados, e há várias filas de furos no próprio cartão. Colocando-o no leitor de cartões detecta apenas cerca de 30MB no total, RAW. É provavelmente ou a unidade original a reportar incorrectamente o cartão como defeituoso (como se a protecção de escrita de um verdadeiro cartão SD estivesse ligada) ou um mau contacto algures.

Se nada mais, tenho agora um cartão Micro SD de 8GB de reserva… assim que descobrir como formatá-lo como 8GB. O que não parece ser possível (Windows, Partedmagic, dd, DBAN… nope, ainda 30MB). Ah bem…

Actualização 3

Tive mais alguns destes. O segundo falhou de forma semelhante (leia-se apenas) hoje. Dos restantes, dois foram detectados como leitores de cartões vazios/unformatados, dependendo do tremor (contacto defeituoso?). Um foi detectado como 1/3 cheio, e tinha um nome de volume estranho.

H2testw resultados (no último totalmente funcional que tenho!):

Embora isto seja um pouco preocupante, é evidente que as unidades têm de facto uma capacidade próxima dos 8GB, como verificado por uma ferramenta frequentemente utilizada com sucesso para detectar unidades flash falsas. A utilização de um cartão Micro SD em vez de um módulo de memória flash marcado torna quase impossível a refluxagem da unidade, uma vez que as ferramentas de flash da unidade Alcor esperam o modelo de memória como um parâmetro. Acho que vou deitar o lote todo fora.