Portabilidad de enlaces de descriptor de archivo

Siempre me he preguntado esto, pero nunca se tomaron el tiempo para averiguar, por lo que voy a hacer lo que ahora - cómo portátil es el uso que se muestra aquí de cualquiera /proc/$$/fd/$No /dev/fd/$N? Entiendo las garantías POSIX /dev/null, /dev/tty, and /dev/console (aunque solo lo descubrí el otro día después de leer los comentarios sobre esta respuesta ), pero ¿qué pasa con estos otros?

Hasta donde puedo decir, son bastante comunes, pero ¿en qué sistemas no puedo esperar encontrarlos? Por qué no? ¿Es más probable encontrar uno que el otro? ¿Siempre exhibirán atributos similares?

Tiendo a usar estos dispositivos de manera bastante extensa en todo tipo de formas, y me gustaría saber si existe la posibilidad de que me quede corto solo por intentarlo.

Además, las preguntas anteriores deben entenderse como lo que creo que me gustaría saber, pero, dado que obviamente tengo que preguntar en primer lugar, es posible que no sepa lo mejor a este respecto y no deben considerarse requisitos estrictos para una respuesta. Solo dame una pista si puedes, por favor.

Los enlaces simbólicos son casi universales en Linux, pero no existen en ningún otro lugar (excepto en Cygwin que los emula). También existen en AIX y Solaris, pero no son enlaces simbólicos. Portablemente, para obtener información sobre archivos abiertos, instálelo ./proc/PID/fd/NUM/proc/PID/fd/NUMlsof

Se une con /proc/PID/fd

Linux

En Linux, hay un enlace simbólico ligeramente mágico al archivo que el proceso con el ID PID ha abierto en el descriptor de archivo NUM . Este enlace es mágico en el sentido de que, por ejemplo, se puede usar para acceder al archivo incluso si se elimina el archivo. El enlace también rastreará el archivo a través de cambios de nombre. es un enlace simbólico mágico que apunta a donde PID es el proceso que accede al enlace./proc/PID/fd/NUM/proc/self/proc/PID

Esta característica está presente en prácticamente todos los sistemas Linux. Es proporcionado por el controlador para el sistema de archivos proc , que es técnicamente opcional pero utilizado para muchas cosas (incluyendo hacer el pstrabajo, se lee ) que casi nunca se omite, incluso en sistemas integrados./proc/PID

Cygwin

Cygwin emula Linux (para procesos Cygwin) y ./proc/PID/fd/NUM/proc/self

Solaris (desde la versión 2.6), AIX

Hay entradas para cada descriptor de archivo, pero aparecen como el mismo tipo que el archivo abierto, por lo que no proporcionan información sobre la ruta del archivo. Sin embargo, informan la misma información que informaría al proceso que tiene el archivo abierto, por lo que es posible determinar en qué sistema de archivos se encuentra el archivo y su número de inodo. Los directorios aparecen como enlaces simbólicos, sin embargo, son enlaces simbólicos mágicos que solo pueden seguirse y devuelve una cadena vacía./proc/PID/fdstatfstatreadlink

En AIX, el procfilescomando muestra información sobre los archivos abiertos de un proceso. En Solaris, el pfilescomando muestra información sobre los archivos abiertos de un proceso. Esto no incluye la ruta al archivo (en Solaris, lo hace desde Solaris 10, ver más abajo).

Solaris (desde la versión 10 )

Además , las versiones modernas de Solaris tienen enlaces simbólicos similares a los enlaces simbólicos de Linux en . El comando muestra información sobre los archivos abiertos de un proceso, incluidas las rutas./proc/PID/fd/NUM/proc/PID/path/NUM/proc/PID/fd/NUMpfiles

Plan9

/proc/PID/fdes un archivo de texto que contiene un registro (línea) por descriptor de archivo abierto por el proceso. El nombre del archivo no se rastrea allí.

QNX

/proc/PID/ es un directorio, pero no contiene ninguna información sobre descriptores de archivos.

Se une con /procpero sin acceso directo a los descriptores de archivo

(Nota: a veces es posible obtener información sobre los archivos abiertos de un proceso revisando su imagen de memoria a la que se puede acceder /proc. No considero eso como "acceso directo").

Unices donde hay un archivo/proc/PID

El propio sistema de archivos proc comenzó en la 8ª edición de UNIX, pero con una estructura diferente, y pasó por el Plan 9 y regresó a algunas unidades. Creo que todos los sistemas operativos con una /proctienen una entrada para cada PID, pero en muchos sistemas, es un archivo normal, no un directorio. Los siguientes sistemas tienen un que debe leerse con :/proc/PIDioctl

• Solaris hasta 2.5
• OSF / 1 ahora conocido como Tru64
• IRIX (?)
• SCO (?)

MINIX 3

MINIX 3 tiene un servidor procfs que proporciona varios componentes similares a Linux, incluidos directorios. Sin embargo, esto no hay no ./proc/PID//proc/PID/fd

FreeBSD

FreeBSD tiene directorios, pero no proporcionan información sobre descriptores de archivos abiertos. (Sin embargo, existe una similar a la de Linux , que da acceso al ejecutable a través de un enlace simbólico)./proc/PID//proc/PID/file/proc/PID/exe

El proceso de FreeBSD está en desuso .

Unices sin /proc

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

Información del descriptor de archivo a través de otros canales

Fusor

El fusercomando enumera los procesos que tienen un archivo especificado abierto o un archivo abierto en el punto de montaje especificado. Este comando es estándar (disponible en todos los sistemas compatibles con XSI , es decir, POSIX con X / Open System Interface Extension).

No puede pasar de un proceso a nombres de archivos con esta utilidad.

Lsof

Lsof significa "lista de archivos abiertos". Es una herramienta de terceros , disponible (pero generalmente no forma parte de la instalación predeterminada) para la mayoría de las variantes de Unix. La obtención de información sobre archivos abiertos depende mucho del sistema, ya que el análisis anterior podría haberlo hecho sospechar. El mantenedor de lsof ha hecho el trabajo de combinarlo todo en una sola interfaz.

Puede leer las preguntas frecuentes para ver qué tipo de dificultades tiene que soportar lsof. En la mayoría de los equipos, obtener información sobre los nombres de los archivos abiertos requiere analizar las estructuras de datos del núcleo. Citando la pregunta frecuente 3.3 "¿Por qué lsof no informa los nombres completos de las rutas?":

Lsof no puede obtener componentes de nombre de ruta de las memorias caché de nombres de kernel de los siguientes dialectos:

• AIX

Solo el kernel de Linux registra nombres de ruta completos en las estructuras que mantiene sobre los archivos abiertos; en su lugar, la mayoría de los núcleos convierten los nombres de ruta en dobletes de número de dispositivo y nodo y los usan para referencias de archivos posteriores una vez que se han abierto los archivos.

Si necesita analizar información de lsofla salida de, asegúrese de usar el -Fmodo (un campo por línea), preferiblemente el -F0modo (campos delimitados por nulos). Para obtener información sobre un descriptor de archivo específico de un proceso específico, use la -aopción con y , por ejemplo .-p PID-d NUMlsof -a -p 123 -d 0 -F0n

/dev/fd/NUM para descriptores de archivo del proceso actual

Muchas variantes de Unix proporcionan una forma para que un proceso acceda a sus archivos abiertos a través de un nombre de archivo: abrir es equivalente a llamar . Estos nombres son útiles cuando un programa quiere un nombre de archivo pero desea pasar un archivo ya abierto (por ejemplo, una tubería o un socket); por ejemplo, los shells que implementan la sustitución de procesos los usan donde están disponibles (usando una tubería temporal con nombre donde no está disponible)/dev/fd/NUMdup(NUM)/dev/fd

Donde /dev/fdexiste, también suele haber (¿siempre?) Sinónimos (a veces enlaces simbólicos, a veces enlaces duros, a veces archivos mágicos con propiedades equivalentes) /dev/stdin= /dev/fd/0, /dev/stdout= /dev/fd/1, /dev/stderr= /dev/fd/2.

• En Linux, /dev/fdes un enlace simbólico a /proc/self/fd.
• En la mayoría de las unidades ( IRIX , OpenBSD , NetBSD , SCO, Solaris , ...), las entradas /dev/fdson dispositivos de caracteres. Por lo general, aparecen si el descriptor de archivo está abierto o no, y las entradas pueden no estar disponibles para descriptores de archivo por encima de un cierto número.
• Bajo FreeBSD y OSX, el sistema de archivos fdescfs proporciona un /dev/fddirectorio dinámico que sigue los descriptores abiertos del proceso de llamada. Hay una estática /dev/fddisponible /dev/fdque no está montada.
• Bajo OSF / 1 (Tru64), /dev/fdse proporciona a través de fdfs .
• No hay /dev/fden AIX o HP-UX.

La forma en que /procse implementa y las características que proporciona no están estandarizadas de ninguna manera, ver por ejemplo aquí . Según Wikipedia, FreeBSD se está "eliminando gradualmente" /proc, consulte aquí para obtener más detalles .

A partir de /dev, /dev/fd/no forma parte de POSIX ni de la Especificación de usuario único (SUSv3) mientras que el Sistema V y BSD lo admiten.

Apéndice:

Linux: /dev/fd/*son enlaces simbólicos a /proc/self/fd.

FreeBSD: /dev/fd/*se proporciona a través de fdescfs.

NetBSD: igual que FreeBSD.

OpenBSD: igual que FreeBSD.

Solaris: tiene /dev/fd/*.

IRIX: tiene /dev/fd/*.

Tru64 Unix: /dev/fd/*según nixdoc.net , la documentación genuina de Tru64 en HP es inescrutable (¡vaya, qué desastre! ¡No encuentras nada!).

AIX: no se encontró ninguna indicación de la documentación disponible públicamente

HP-UX: igual que AIX.