Portabilidade de links do descritor de arquivo

Eu sempre me perguntei isso, mas nunca tirei um tempo para descobrir, então o farei agora - quão portátil é o uso mostrado aqui de um /proc/$$/fd/$Nou outro /dev/fd/$N? Entendo as garantias POSIX /dev/null, /dev/tty, and /dev/console (embora eu tenha descoberto isso no outro dia depois de ler os comentários sobre esta resposta ), mas e essas outras?

Até onde eu sei, eles são bastante comuns, mas em quais sistemas não posso encontrá-los? Por que não? É mais provável encontrar um que o outro? Eles sempre exibem atributos?

Costumo usar esses dispositivos de várias maneiras, e gostaria de saber se há uma chance de que eu não consiga tentar.

Além disso, as perguntas acima devem ser entendidas como sendo apenas o que eu gostaria de saber, mas, como eu obviamente tenho que perguntar em primeiro lugar, talvez eu não conheça melhor a esse respeito e elas não devem ser consideradas requisitos rigorosos para uma resposta. Apenas me indique se puder, por favor.

Os links simbólicos são quase universais no Linux, mas eles não existem em nenhum outro lugar (exceto no Cygwin que os emula). também existem no AIX e Solaris, mas não são links simbólicos. Portably, para obter informações sobre arquivos abertos, instale ./proc/PID/fd/NUM/proc/PID/fd/NUMlsof

Unices with /proc/PID/fd

Linux

No Linux, existe um link simbólico levemente mágico para o arquivo que o processo com o ID PID abriu no descritor de arquivo NUM . Esse link é mágico, pois, por exemplo, ele pode ser usado para acessar o arquivo, mesmo que ele seja removido. O link também rastreará o arquivo através de renomeações. é um link simbólico mágico que aponta para onde o PID é o processo que acessa o link./proc/PID/fd/NUM/proc/self/proc/PID

Esse recurso está presente em praticamente todos os sistemas Linux. Ele é fornecido pelo driver para o sistema de arquivos proc , que é tecnicamente opcional, mas é usado para muitas coisas (inclusive para fazer o pstrabalho - lê-se ) que quase nunca é deixado de fora, mesmo em sistemas embarcados./proc/PID

Cygwin

Cygwin emula Linux's (para processos Cygwin) e ./proc/PID/fd/NUM/proc/self

Solaris (desde a versão 2.6), AIX

Existem entradas para cada descritor de arquivo, mas elas aparecem como o mesmo tipo que o arquivo aberto e, portanto, não fornecem informações sobre o caminho do arquivo. No entanto, eles relatam as mesmas informações que relatariam ao processo que tem o arquivo aberto, portanto, é possível determinar em qual sistema de arquivos o arquivo está localizado e seu número de inode. Os diretórios aparecem como links simbólicos, no entanto, são links simbólicos mágicos que só podem ser seguidos e retornam uma string vazia./proc/PID/fdstatfstatreadlink

No AIX, o procfilescomando exibe algumas informações sobre os arquivos abertos de um processo. No Solaris, o pfilescomando exibe algumas informações sobre os arquivos abertos de um processo. Isso não inclui o caminho para o arquivo (no Solaris, desde o Solaris 10, veja abaixo).

Solaris (desde a versão 10 )

Além disso , as versões modernas do Solaris possuem links simbólicos semelhantes aos links simbólicos do Linux . O comando mostra informações sobre os arquivos abertos de um processo, incluindo caminhos./proc/PID/fd/NUM/proc/PID/path/NUM/proc/PID/fd/NUMpfiles

Plano9

/proc/PID/fdé um arquivo de texto que contém um registro (linha) por descritor de arquivo aberto pelo processo. O nome do arquivo não é rastreado lá.

QNX

/proc/PID/ é um diretório, mas não contém nenhuma informação sobre descritores de arquivo.

Unices com /procmas sem acesso direto aos descritores de arquivos

(Nota: às vezes é possível obter informações sobre os arquivos abertos de um processo, vasculhando sua imagem de memória que está acessível em /proc. Não conto isso como "acesso direto".)

Unifica onde está um arquivo/proc/PID

O sistema de arquivos proc começou na 8ª edição do UNIX, mas com uma estrutura diferente, e passou pelo Plano 9 e voltou para alguns departamentos. Eu acho que todos os sistemas operacionais com /procuma entrada têm para cada PID, mas em muitos sistemas, é um arquivo regular, não um diretório. Os seguintes sistemas têm um que precisa ser lido com :/proc/PIDioctl

• Solaris até 2,5
• OSF / 1 agora conhecido como Tru64
• IRIX (?)
• SCO (?)

MINIX 3

O MINIX 3 possui um servidor procfs que fornece vários componentes semelhantes ao Linux, incluindo diretórios. No entanto, isso não existe, não ./proc/PID//proc/PID/fd

FreeBSD

O FreeBSD possui diretórios, mas eles não fornecem informações sobre descritores de arquivos abertos. (No entanto, é semelhante ao Linux , dando acesso ao executável através de um link simbólico.)/proc/PID//proc/PID/file/proc/PID/exe

O procfs do FreeBSD está obsoleto .

Unices sem /proc

• HP-UX
• OpenBSD
• NetBSD
• Mac OS X

Informações do descritor de arquivo por outros canais

Fusor

O fusercomando lista os processos que têm um arquivo especificado aberto ou um arquivo aberto no ponto de montagem especificado. Este comando é padrão (disponível em todos os sistemas compatíveis com XSI , ou seja, POSIX com o X / Open System Interface Extension).

Você não pode passar de um processo para nomes de arquivos com este utilitário.

Lsof

Lsof significa "listar arquivos abertos". É uma ferramenta de terceiros , disponível (mas geralmente não faz parte da instalação padrão) para a maioria das variantes unix. A obtenção de informações sobre arquivos abertos depende muito do sistema, pois a análise acima pode ter feito você suspeitar. O mantenedor lsof fez o trabalho de combinar tudo isso em uma única interface.

Você pode ler as Perguntas frequentes para ver quais tipos de dificuldades o lsof tem de aturar. Na maioria das unidades, a obtenção de informações sobre os nomes dos arquivos abertos requer a análise das estruturas de dados do kernel. Citando a partir da FAQ 3.3 "Por que o lsof não informa nomes de caminhos completos?":

O Lsof não pode obter os componentes do nome do caminho nos caches de nomes do kernel dos seguintes dialetos:

• AIX

Somente o kernel do Linux registra nomes de caminhos completos nas estruturas que mantém sobre arquivos abertos; em vez disso, a maioria dos kernels converte nomes de caminhos em dupletos de número de dispositivo e nó e os usa para referências de arquivo subseqüentes depois que os arquivos forem abertos.

Se você precisar analisar as informações da lsofsaída de, certifique-se de usar o -Fmodo (um campo por linha), de preferência o -F0modo (campos delimitados por nulo). Para obter informações sobre um descritor de arquivo específico de um processo específico, use a -aopção com e , por exemplo .-p PID-d NUMlsof -a -p 123 -d 0 -F0n

/dev/fd/NUM para descritores de arquivo do processo atual

Muitas variantes do unix fornecem uma maneira de um processo acessar seus arquivos abertos por meio de um nome de arquivo: abertura é equivalente a chamada . Esses nomes são úteis quando um programa deseja um nome de arquivo, mas você deseja passar um arquivo já aberto (por exemplo, um cano ou soquete); por exemplo, os shells que implementam a substituição do processo os utilizam quando disponíveis (usando um pipe nomeado temporário quando não está disponível)./dev/fd/NUMdup(NUM)/dev/fd

Onde /dev/fdexiste, também costuma haver (sempre?) Sinônimos (algumas vezes links simbólicos, outras vezes hard links, outras vezes arquivos mágicos com propriedades equivalentes) /dev/stdin= /dev/fd/0, /dev/stdout= /dev/fd/1, /dev/stderr= /dev/fd/2.

• No Linux, /dev/fdé um link simbólico para /proc/self/fd.
• Na maioria dos departamentos ( IRIX , OpenBSD , NetBSD , SCO, Solaris ,…), as entradas /dev/fdsão dispositivos de caracteres. Eles geralmente aparecem se o descritor de arquivo está aberto ou não e as entradas podem não estar disponíveis para descritores de arquivo acima de um determinado número.
• No FreeBSD e OSX, o sistema de arquivos fdescfs fornece um /dev/fddiretório dinâmico que segue os descritores abertos do processo de chamada. Uma estática /dev/fdestá disponível /dev/fde não está montada.
• Sob OSF / 1 (Tru64), /dev/fdé fornecido via fdfs .
• Não há /dev/fdno AIX ou HP-UX.

O modo /procé implementado e os recursos que ele fornece não são padronizados de forma alguma, veja, por exemplo, aqui . De acordo com a Wikipedia, o FreeBSD está "desaparecendo" /proc, veja aqui para detalhes .

A partir de /dev, /dev/fd/não faz parte do POSIX ou da Single User Specification (SUSv3), enquanto o System V e o BSD o suportam.

Termo aditivo:

Linux: /dev/fd/*são links simbólicos para /proc/self/fd.

FreeBSD: /dev/fd/*é fornecido através do fdescfs.

NetBSD: igual ao FreeBSD.

OpenBSD: igual ao FreeBSD.

Solaris: tem /dev/fd/*.

IRIX: tem /dev/fd/*.

Tru64 Unix: /dev/fd/*segundo o nixdoc.net , a documentação genuína do Tru64 na HP é inescrutável (garoto, que bagunça! Você não encontra nada!).

AIX: nenhuma indicação encontrada na documentação publicamente disponível.

HP-UX: igual ao AIX.