O que causa erros ENOENT?

O que causa erros ENOENT?

Estou executando um script Node e recebo este erro neste caminho:

 ENOENT ../../../Library/Application Support/Google/Chrome/RunningChromeVersion

Posso remover o erro fechando o Chrome.

A maior parte da minha pesquisa no Google me disse queENOENTEos erros são causados ​​por arquivos/pastas que não saem.

No entanto, neste caso a pasta existe claramente e tem a ver com o fato de o Chrome estar em execução.

Quero poder percorrer os arquivos mesmo que eles estejam em uso. Isso é possível?

A maioria dos outros erros é causada pela Apple e estou em uma máquina Apple.

ENOENT ../../../Library/Containers/com.apple..NowPlayingWidgetContainer/Data/Documents/iChats

Responder1

O item nomeado RunningChromeVersionexiste, mas é umligação simbólicacujoalvonão existe. Seu script Node não dá nenhum tratamento especial aos links, então a ação padrão ao tentar abri-los é seguir o link.

O destino do link não existe porque, em primeiro lugar, não se destina a apontar para um arquivo. É um link fictício com algumas informações não relacionadas (por exemplo, um número de versão) armazenadas no campo 'target', onde normalmente ficaria um nome de arquivo.

Por exemplo, aqui está o equivalente no Linux (observe a lindicação “type”):

$ ls -l ~/.config/chromium
total de 4,2 milhões
...
drwx ------ 3 usuários grawity 4.0K 14 de maio 09:52 ShaderCache/
eurwxrwxrwx 1 usuários grawity 20 17 de maio 13:38 SingletonCookie-> 18396286875963223082
eurwxrwxrwx 1 usuários grawity 12 17 de maio 13:38 SingletonLock-> geada-453916
eurwxrwxrwx 1 usuários grawity 50 17 de maio 13:38 SingletonSocket-> /tmp/.org.chromium.Chromium.7Og2ow/SingletonSocket=
drwx ------ 3 usuários grawity 4.0K 27 de dezembro 08:02 SSLErrorAssistant /
...

Este é um método comum de criação de "arquivos de bloqueio"; é necessário apenas um syscall para criar um link atomicamente (e falhar se ele já existir), um syscall para ler seu "conteúdo" (o campo 'destino') e acho que é até compatível com NFS/SMB/AFS, enquanto o arquivo real os bloqueios tendem a funcionar menos bem com esses sistemas de arquivos de rede.

Se você usar readdir() para varrer diretórios, então cada entrada de diretório já terá informações sobre seu tipo: por exemplo, no Node, você pode chamar.isSymbolicLink()em cada resultado readdir.

Se você tiver apenas o caminho, poderá usar o Node equivalente aolstat()função para verificar se um caminho é um link simbólico e evitar atravessá-lo dessa forma (também é necessário readlink()ler seu campo 'destino', se desejar).

Na verdade érecomendadopara pular links simbólicos ao fazer pesquisa recursiva de arquivos, porque seguir links simbólicos pode levar você a um loop infinito (por exemplo, dirA/linkB aponta para ../dirB, mas dirB/linkA aponta para ../dirA, e agora você está preso).

informação relacionada