Não é possível ler o arquivo normal - bloco de operações de E / S

Question

Estou escrevendo um programa que analisa todos os arquivos em um dispositivo Android, procurando por uma string específica. Alguns segundos durante o processo, fico preso no seguinte arquivo:

/ sys / power / wakelock_count

Eu tentei usar o grep , a função C fopen , bem como outras alternativas, e todos bloqueiam IO neste arquivo - eles simplesmente nunca retornam. Seu tamanho é exatamente 4096 bytes, mas usando stat ou ls -l o arquivo é reportado como um arquivo regular - nenhum link simbólico, nenhum arquivo de dispositivo . Eu verifiquei por alças abertas - este arquivo é aberto por system_se , que também acontece a segurar alças para dezenas de outros arquivos, que eu posso ler muito bem. Também verifiquei bloqueios e não há bloqueios OBRATÓRIOS que impeçam o acesso de leitura.

O que há de tão especial sobre esse arquivo e como posso lê-lo ou ignorá-lo?

EDIT: Estou executando todas as operações como SU.

EDIT2: resultado ls -ld :

-rw-r--r-- 1 system system 4096 1971-10-10 21:59 wakeup_count

    

Answer 1

Observe que /sys/power/wakeup_count não é realmente um arquivo "regular" porque não está em um sistema de arquivos "regular". É quase certo em um sistema de arquivos "sysfs-power", que é semelhante ao sistema de arquivos "proc", pois não representa realmente nada como arquivos em discos.

Por a documentação do sistema de arquivos sysfs-power :

What:       /sys/power/wakeup_count
Date:       July 2010
Contact:    Rafael J. Wysocki <[email protected]>
Description:
        The /sys/power/wakeup_count file allows user space to put the
        system into a sleep state while taking into account the
        concurrent arrival of wakeup events.  Reading from it returns
        the current number of registered wakeup events and it blocks if
        some wakeup events are being processed at the time the file is
        read from.  Writing to it will only succeed if the current
        number of wakeup events is equal to the written value and, if
        successful, will make the kernel abort a subsequent transition
        to a sleep state if any wakeup events are reported after the
        write has returned.

Portanto, suspender as leituras pode não ser um problema, embora pendurar por um longo tempo não parece ser provável, dada a documentação acima.

No entanto, é bem possível que você esteja encontrando esse bug: Lendo de / sys / power / wakeup_count está pendurado indefinidamente Isso é exatamente o mesmo que você descreve.