Cómo encontrar la fecha de creación de archivos en Linux: Guía técnica completa

Linux no expone de forma nativa el tiempo de creación de archivos a través de la mayoría de las herramientas estándar de espacio de usuario, pero los datos subyacentes a menudo existen — el desafío es saber exactamente dónde buscar y qué sistema de archivos y versión del kernel está ejecutando. En los sistemas de archivos ext4, btrfs, xfs y tmpfs con Linux kernel 4.11+, los verdaderos timestamps de creación (crtime) se almacenan en el inodo y son recuperables a través de utilidades específicas de bajo nivel. En sistemas de archivos o kernels más antiguos, debe usar una combinación de metadatos de inodo, registros del sistema y depuradores específicos del sistema de archivos para aproximar el tiempo de creación.

Esta guía cubre todos los métodos confiables disponibles en 2024, incluyendo sus requisitos técnicos previos, sintaxis exacta de comandos, modos de fallo conocidos y cuándo cada enfoque es apropiado para la administración de sistemas en producción.

Por qué el tiempo de creación de archivos en Linux no es sencillo

Cada archivo en Linux está descrito por un inodo — una estructura de datos que almacena metadatos como permisos, propiedad, tamaño y timestamps. El estándar POSIX históricamente definió tres timestamps:

• atime — tiempo del último acceso
• mtime — tiempo de la última modificación (contenido cambiado)
• ctime — tiempo de cambio del inodo (metadatos o contenido cambiados)

Fundamentalmente, ctime no es el tiempo de creación. Este es uno de los conceptos erróneos más comunes entre los administradores que migran desde entornos Windows. ctime se actualiza cada vez que cambian los permisos, la propiedad o se renombra el archivo — no tiene nada que ver con cuándo se creó el archivo por primera vez.

El tiempo de creación real, conocido como birth time o crtime, fue añadido a la estructura del inodo ext4 y se expone a través de la llamada al sistema statx() introducida en Linux kernel 4.11. Sin embargo, muchas distribuciones incluían herramientas que no mostraban estos datos hasta hace relativamente poco, razón por la cual persiste la confusión.

Requisitos previos de sistema de archivos y kernel

Antes de intentar cualquier método, verifique su entorno:

# Check kernel version
uname -r

# Check filesystem type for a specific path
df -T /path/to/your/file

# Check filesystem mount options
findmnt -o TARGET,FSTYPE,OPTIONS /path/to/your/file

Si está ejecutando un entorno de VPS Hosting, el sistema de archivos subyacente es casi siempre ext4 o btrfs, lo que significa que los datos de birth time están disponibles — solo necesita las herramientas adecuadas para acceder a ellos.

Método 1: Usando el comando stat (Punto de partida recomendado)

El comando stat es la primera herramienta correcta a probar. En sistemas modernos con kernel 4.11+ y un sistema de archivos compatible, mostrará directamente el campo Birth.

stat /path/to/your/file

Ejemplo de salida en un sistema ext4 moderno:

  File: /home/deploy/app/config.yml
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 2883591     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  deploy)   Gid: ( 1000/  deploy)
Access: 2024-03-15 09:22:14.812345678 +0000
Modify: 2024-03-10 14:05:33.123456789 +0000
Change: 2024-03-10 14:05:33.123456789 +0000
 Birth: 2024-03-08 11:47:02.987654321 +0000

Si el campo Birth muestra - (un guión) en lugar de un timestamp, una de las siguientes situaciones es verdadera:

• El sistema de archivos no almacena birth time (ext2/ext3)
• El kernel es anterior a la versión 4.11
• El binario stat está desactualizado y no llama a statx()
• El archivo fue creado antes de que el sistema de archivos fuera actualizado de ext3 a ext4

Extracción únicamente del timestamp de creación de forma programática:

stat --format="%w" /path/to/your/file
# Returns '-' if unavailable, or ISO 8601 timestamp if available

stat --format="%W" /path/to/your/file
# Returns Unix epoch integer (0 if unavailable)

El formato %W que devuelve 0 es una verificación programática confiable de si el birth time está genuinamente no disponible.

Método 2: Usando debugfs para sistemas de archivos ext4

debugfs es la herramienta definitiva de bajo nivel para la inspección de inodos ext4. Lee la estructura del inodo en bruto y puede exponer crtime incluso cuando stat falla debido a un binario de espacio de usuario más antiguo.

Paso 1: Identificar el número de inodo de su archivo

ls -i /path/to/your/file
# Output example: 2883591 /path/to/your/file

Paso 2: Identificar el dispositivo de bloque que aloja el sistema de archivos

df /path/to/your/file
# Output shows the device, e.g., /dev/sda1 or /dev/vda1

Paso 3: Consultar debugfs con el número de inodo

sudo debugfs -R 'stat <2883591>' /dev/vda1

Reemplace 2883591 con su número de inodo real y /dev/vda1 con su dispositivo real. La salida incluirá un campo crtime:

Inode: 2883591   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 3421897654    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4096
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
 atime: 0x65f4a1ae:c6b5c000 -- Fri Mar 15 09:22:14 2024
 mtime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
crtime: 0x65e4b2c6:eb851400 -- Thu Mar 08 11:47:02 2024
Size of extra inode fields: 28

Nota operativa importante: debugfs abre el sistema de archivos en modo de solo lectura por defecto cuando se usa -R, pero aun así debe evitar ejecutarlo en un sistema de archivos muy activo sin desmontarlo primero o usar una instantánea. En Servidores Dedicados en producción, siempre prefiera ejecutar debugfs contra una instantánea del sistema de archivos o un volumen en reposo para evitar leer un estado de inodo inconsistente.

Sintaxis alternativa usando el nombre de archivo directamente:

sudo debugfs -R "stat /path/to/your/file" /dev/vda1

Tenga en cuenta que la ruta aquí debe ser relativa a la raíz del sistema de archivos, no a la raíz del sistema. Si /dev/vda1 está montado en /, entonces /path/to/your/file funciona tal cual.

Método 3: Usando xfs_db para sistemas de archivos XFS

En sistemas de archivos XFS (comunes en sistemas RHEL/CentOS/Rocky Linux), el equivalente de debugfs es xfs_db.

# Get inode number first
ls -i /path/to/your/file

# Unmount or use read-only mode
sudo xfs_db -r /dev/sda1 -c "inode <inode_number>" -c "print"

Busque el campo v3.crtime en la salida. XFS v5 (el predeterminado desde RHEL 7) almacena el birth time de forma nativa. XFS v4 no lo hace.

Método 4: Usando la inspección de subvolumen y archivo btrfs

En btrfs, stat con un kernel moderno es suficiente y completamente confiable. Sin embargo, para una inspección más profunda:

sudo btrfs inspect-internal dump-tree /dev/sdb | grep -A 20 "inode ref"

Para propósitos prácticos en btrfs, el campo Birth de la salida de stat es autoritativo.

Método 5: Consultando statx() directamente a través de Python

Cuando las herramientas de shell dan resultados inconsistentes, llamar a la syscall statx() directamente desde Python proporciona una respuesta definitiva:

import os
import stat

result = os.stat("/path/to/your/file")
# st_birthtime is available on systems where statx() returns it
if hasattr(result, 'st_birthtime'):
    import datetime
    birth = datetime.datetime.fromtimestamp(result.st_birthtime)
    print(f"Birth time: {birth}")
else:
    print("Birth time not available on this platform/filesystem")

Para una resolución de nanosegundos más precisa, use el módulo ctypes para llamar a statx() directamente — esto es útil en scripts forenses donde la precisión del timestamp importa.

Método 6: Búsqueda en registros del sistema

Cuando el birth time a nivel de sistema de archivos no está disponible — por ejemplo, en sistemas de archivos ext3 o archivos que son anteriores a una conversión del sistema de archivos — los registros del sistema se convierten en la alternativa.

Buscar en el journal de systemd:

journalctl --since="2024-01-01" | grep "your_filename"

Buscar en el syslog tradicional:

grep "your_filename" /var/log/syslog
grep "your_filename" /var/log/messages

Buscar en el registro de auditoría (si auditd está configurado):

sudo ausearch -f /path/to/your/file

El subsistema de auditoría es el método más confiable basado en registros porque registra las syscalls openat(), creat() y rename() con timestamps precisos. Sin embargo, debe configurarse con anticipación — no puede auditar retroactivamente eventos de creación de archivos que ocurrieron antes de que auditd estuviera habilitado.

Habilitar la auditoría de creación de archivos para un directorio:

sudo auditctl -w /var/www/html -p w -k web_file_creation

Esto monitorea /var/www/html para eventos de escritura, etiquetándolos con la clave web_file_creation para una fácil recuperación.

Método 7: Usando ls — Comprendiendo sus limitaciones

El comando ls se cita frecuentemente en guías como una forma de verificar el tiempo de creación, pero esto requiere una calificación significativa.

ls -l --time=birth /path/to/your/file
ls -l --time=creation /path/to/your/file  # synonym on some systems

Advertencia crítica: ls --time=birth solo funciona en GNU coreutils 8.25+ y solo cuando el sistema de archivos subyacente y el kernel admiten birth time. Si el birth time no está disponible, ls silenciosamente recurre a mtime sin ninguna advertencia. Esta recuperación silenciosa es un riesgo operativo significativo — puede creer que está leyendo el tiempo de creación mientras en realidad está leyendo el tiempo de modificación.

Siempre verifique primero con stat. Use ls solo para propósitos de visualización, no para lógica en scripts.

# Safer: check stat output explicitly before relying on ls
BIRTH=$(stat --format="%W" /path/to/your/file)
if [ "$BIRTH" -eq 0 ]; then
    echo "Birth time unavailable, falling back to mtime"
    stat --format="%y" /path/to/your/file
else
    echo "Birth time: $(date -d @$BIRTH)"
fi

Comparación de métodos y matriz de decisión

Casos límite del mundo real y errores comunes

Archivo copiado vs. movido: Cuando se copia un archivo (cp), el destino obtiene un nuevo inodo con un nuevo birth time. Cuando se mueve un archivo dentro del mismo sistema de archivos (mv), el inodo se preserva y el birth time no cambia. mv entre sistemas de archivos se comporta como cp + rm, creando un nuevo inodo.

Conversión del sistema de archivos de ext3 a ext4: Los archivos que existían antes de la conversión tendrán un crtime de cero en su inodo, porque ext3 nunca pobló ese campo. debugfs mostrará crtime: 0x00000000:00000000. En este caso, mtime en el momento de la conversión es la mejor aproximación.

Docker y entornos de contenedores: Los sistemas de archivos de contenedores (overlay2, aufs) pueden no propagar el birth time correctamente. Los archivos dentro de los contenedores pueden mostrar el birth time como el tiempo de inicio del contenedor en lugar del tiempo real de creación del archivo.

Montajes NFS: La disponibilidad del birth time depende completamente del sistema de archivos del servidor NFS. El cliente no tiene datos de birth time independientes.

Restauración de copias de seguridad: Los archivos restaurados desde archivos tar típicamente obtienen un nuevo inodo y por lo tanto un nuevo birth time que refleja la fecha de restauración, no la fecha de creación original. Use tar --preserve-permissions y verifique mtime para la aproximación más cercana al tiempo de creación original.

Para los administradores que gestionan aplicaciones web en VPS con cPanel, la integridad de los timestamps de archivos es particularmente importante durante las migraciones — siempre verifique los metadatos del inodo después de restaurar desde una copia de seguridad.

Habilitando el soporte de birth time: Ajuste del sistema de archivos

Si está configurando un nuevo servidor y desea soporte garantizado de birth time, asegúrese de lo siguiente:

Para ext4 — verificar que el tamaño del inodo sea de 256 bytes (requerido para el campo crtime):

sudo tune2fs -l /dev/vda1 | grep "Inode size"
# Should return: Inode size: 256

Si el tamaño del inodo es 128, el birth time no puede almacenarse. Esto requiere reformatear — no puede cambiarse en un sistema de archivos existente.

Crear un nuevo sistema de archivos ext4 con inodos de 256 bytes (predeterminado desde e2fsprogs 1.41):

sudo mkfs.ext4 -I 256 /dev/vdb1

Verificar que el kernel admite statx():

uname -r  # Must be >= 4.11

Al aprovisionar nueva infraestructura — ya sea Hosting Web Compartido o Servidores Dedicados de metal desnudo — confirme el tamaño del inodo del sistema de archivos antes de implementar aplicaciones que dependan de los metadatos de birth time.

Lista de verificación práctica para determinar el tiempo de creación de archivos

Use este árbol de decisión cuando necesite encontrar la fecha de creación de un archivo:

• Verificar la versión del kernel primero: uname -r — debe ser 4.11+ para que stat muestre Birth
• Verificar el tipo de sistema de archivos: df -T /path/to/file — se requiere ext4, btrfs o xfs v5
• Ejecutar stat en el archivo: Si el campo Birth muestra un timestamp, tiene su respuesta
• Si Birth muestra -: Ejecutar debugfs (ext4) o xfs_db (xfs) con el número de inodo
• Si el sistema de archivos es ext3 o ext2: Recurrir a mtime como mejor aproximación
• Si necesita precisión de nivel de auditoría en el futuro: Configure auditd ahora
• Si el archivo fue creado recientemente: Verifique journalctl para entradas de registro corroborantes
• En scripts: Siempre verifique stat --format="%W" para 0 antes de confiar en el valor
• Después de migraciones o restauraciones: Trate el birth time como sospechoso; haga referencias cruzadas con mtime y manifiestos de copia de seguridad

Para entornos donde la integridad de archivos y la precisión de timestamps son requisitos de seguridad — como aplicaciones que manejan Certificados SSL y archivos de claves criptográficas — combinar auditd con el birth time a nivel de sistema de archivos le proporciona un enfoque de verificación de dos capas que es defendible en auditorías de seguridad.

Preguntas frecuentes

¿Linux siempre almacena el tiempo de creación de archivos?

No. Solo los sistemas de archivos con inodos de 256 bytes (ext4, btrfs, xfs v5) almacenan el birth time. ext2 y ext3 no tienen un campo de birth time en su estructura de inodo. Incluso en sistemas de archivos compatibles, los archivos creados antes de una actualización del sistema de archivos de ext3 a ext4 tendrán un birth time de cero.

¿Cuál es la diferencia entre ctime y birth time en Linux?

ctime es el tiempo de cambio del inodo — se actualiza cada vez que cambian los metadatos del archivo (permisos, propiedad, recuento de enlaces) o el contenido. No es el tiempo de creación. El birth time (crtime) se establece una vez cuando el archivo se crea por primera vez y nunca cambia. Muchos administradores confunden estos dos, lo que lleva a conclusiones de auditoría incorrectas.

¿Puedo recuperar el tiempo de creación de un archivo después de que se haya perdido?

Si el campo crtime del inodo es cero o el sistema de archivos no lo admite, el tiempo de creación original no puede recuperarse solo del sistema de archivos. Sus mejores opciones son: verificar los registros de auditd si estaban configurados, buscar en los registros de la aplicación, o consultar manifiestos de copia de seguridad que registraron los metadatos del archivo en el momento de la copia de seguridad.

¿Por qué ls --time=creation muestra el tiempo incorrecto?

ls silenciosamente recurre a mtime cuando el birth time no está disponible, sin mostrar ninguna advertencia. Este es un problema de comportamiento conocido en GNU coreutils. Siempre use stat --format="%W" para verificar programáticamente si el birth time está genuinamente disponible antes de confiar en la salida de ls.

¿Qué comando proporciona el tiempo de creación de archivos más confiable en ext4?

debugfs -R 'stat <inode_number>' /dev/device es el método más confiable en ext4 porque lee la estructura del inodo en bruto directamente, evitando cualquier limitación de las herramientas de espacio de usuario. Para uso diario en kernel 4.11+, stat filename con el campo Birth es equivalente y mucho más conveniente.