Indicador de tipo de archivo, sys / stat.h st_mode valor de código de archivo normal
-
22-07-2019 - |
Pregunta
Estoy intentando identificar tipos de archivos para entradas de directorio (Windows Unix, etc.).
En sys / stat.h, el nybble de orden superior de la palabra st_mode tiene los valores codificados:
#define S_IFDIR 0x4000 /* directory */
#define S_IFIFO 0x1000 /* FIFO special */
#define S_IFCHR 0x2000 /* character special */
#define S_IFBLK 0x3000 /* block special */
#define S_IFREG 0x8000 /* or just 0x0000, regular */
Del comentario parece que el nybble podría ser 0 u 8 para representar un 'archivo normal'.
Entonces esto plantea la pregunta: ¿en qué circunstancias es 0 y no 8? Si hubiera definido estos códigos, habría reservado 0 para iniciar desconocido / indefinido / inválido / no es un archivo o algo así.
De hecho, la macro S_ISREG es:
#define S_ISREG(m) ((m) & S_IFREG)
Esto me parece indicar que un archivo normal debería siempre se espera que tenga el código 8 (¿y 0 sería una aberración?).
¿Sería una suposición válida interpretar 0 como un archivo desconocido o inválido e ignorar el comentario 'o solo 0x0000' y siempre esperar que se use 8 para todos los archivos normales?
Solución
La mayoría de las fuentes indican que verificar S_ISREG es suficiente; No estoy seguro de cuándo vería 0x0000 como "normal" expediente.
Creo que algunas implementaciones antiguas usaban 0x0000 (una búsqueda de encabezado DJGPP realmente antigua lo activa) pero es la única referencia real que puedo encontrar. Todo lo demás apunta a 0x8000.
Básicamente, use la macro S_ISREG y espere que el encabezado de lo que sea que esté compilando haga lo correcto.
Otros consejos
Confiaría en las definiciones de S_IFREG y S_ISREG. Nunca he trabajado con un sistema de archivos que rompió esas macros.
Supongo que la definición 0x0000 para un archivo normal es manejar sistemas de archivos heredados que pueden haber usado una codificación diferente de la información del tipo de archivo. ¿Qué sistema operativo y sistema de archivos estás usando?