Tools: Tar en macOS destroza archivos en Linux: lo validé en mi pipeline real de Railway y documenté los 3 casos que nadie menciona
Tar en macOS destroza archivos en Linux: lo validé en mi pipeline real de Railway y documenté los 3 casos que nadie menciona
Tar macOS Linux error de extracción en producción: el contexto que importa
Los 3 casos reales donde tar macOS rompe un pipeline de Railway
Caso 1: Los archivos ._* de metadata Apple
Caso 2: Permisos que cambian silenciosamente
Caso 3: Paths con espacios en nombres de archivos
Los errores que cometí antes de entender el patrón
Mi configuración actual en Railway
Esto conecta con algo más grande que tar
FAQ: tar macOS Linux error de extracción en producción
Conclusión: el fix es fácil, pero la trampa no es técnica Hay un hilo en Hacker News que resurfaceó esta semana con 107 puntos sobre un artículo de 2024: tar en macOS crea archivos que Linux no puede extraer limpiamente. La comunidad reaccionó como siempre: "usá GNU tar", "instalá gtar con homebrew", "esto es conocido desde hace años". Y sí, todo eso es correcto. Pero hay algo que nadie está diciendo: los 3 escenarios específicos donde esto efectivamente rompe producción no son iguales entre sí, y cada uno tiene un fix distinto. Aprendí esto de la peor manera posible — con un deploy fallido a las 11pm que me llevó dos horas diagnosticar. Mi tesis es que la respuesta "usá GNU tar" es necesaria pero insuficiente si no sabés exactamente por qué tu caso particular explota. Desde que migré de Vercel a Railway en 2024 (un fin de semana que me enseñó más sobre infraestructura real que meses de tutoriales), mi pipeline de deployment depende de artefactos .tar.gz que genero en macOS y extraigo en contenedores Linux. Durante meses funcionó bien. Hasta que no funcionó. El problema de fondo es que BSD tar (el que viene en macOS) y GNU tar (el que corre en Ubuntu, Alpine, Debian) no son el mismo programa. Comparten nombre y sintaxis básica, pero difieren en cómo manejan metadatos extendidos. macOS agrega metadata del sistema de archivos HFS+/APFS que GNU tar no espera encontrar, y cuando la encuentra, puede ignorarla silenciosamente, fallar con warnings que no interrumpen el proceso, o — el peor caso — extraer archivos corruptos sin avisarte. Verificá qué versión de tar tenés en macOS: No son el mismo programa. Nunca lo fueron. Este fue el primer bug que encontré. Cuando macOS crea un .tar.gz desde una carpeta que tocaste con el Finder (o que tuvo atributos extendidos en algún momento), incluye archivos ._nombre_archivo con metadata HFS. Son invisibles en el Finder, pero están en el tar. En mi caso específico, tenía un script de Railway que tomaba el primer archivo .js del directorio para calcular un hash de verificación. El script encontraba ._chunk-abc123.js antes que chunk-abc123.js y el hash fallaba. El deploy completaba, pero la verificación post-deploy lanzaba una alerta. Tardé 90 minutos en conectar esos puntos. La variable de entorno COPYFILE_DISABLE=1 es la más limpia porque actúa en el momento de creación. Sin embargo, si ya tenés archivos .tar.gz viejos en storage, necesitás la opción de filtrado en extracción. Este me costó más porque no había error. El deploy completaba verde, la app levantaba, pero ciertos endpoints devolvían 403. El contenedor no podía leer archivos que, en mi máquina local, tenían permisos 644. El problema: BSD tar en macOS puede serializar permisos de manera diferente para archivos con ACLs (Access Control Lists) de APFS. Cuando GNU tar los extrae, interpreta esos permisos de una forma que puede resultar en bits distintos a los originales. No pasa siempre. Pasa cuando el archivo tuvo algún atributo extendido en algún momento de su historia en el filesystem de macOS. Es el tipo de bug que aparece en producción pero no en staging porque staging tiene otro historial de archivos. La segunda opción es superior porque resuelve el problema en el origen, no en el destino. Si el problema aparece en el destino, ya dependés de que todos los Dockerfiles tengan el fix — y eventualmente alguien va a crear uno nuevo sin él. Este es el más silencioso y el que el artículo de HN original no menciona con suficiente detalle. Si empaquetás desde macOS y algún archivo en el path tiene un espacio (cosa que en macOS el Finder hace completamente normal), el comportamiento de extracción en Linux depende de la versión exacta de GNU tar y cómo procesás la lista de archivos. El tar en sí extrae correctamente con tar -xzf. El problema aparece cuando cualquier script downstream procesa la lista de archivos asumiendo que no hay espacios. En mi caso era un script de invalidación de CDN que leía los paths del tar para saber qué cachés limpiar. La renominación en origen es más robusta porque eliminás la fuente del problema. La iteración con read es un parche que funciona pero que el próximo developer va a romper cuando copie el loop sin entender por qué estaba escrito así. Error 1: Confiar en que "el tar funcionó antes, va a funcionar siempre". Los archivos ._* aparecieron después de que empecé a abrir esa carpeta de assets con el Finder para preview. Antes del Finder, no había metadata. Después del Finder, sí. El pipeline era el mismo; el filesystem no. Error 2: Leer solo los exit codes. GNU tar extrae archivos ._* con exit code 0. No hay error. Tu deploy está "verde" y en producción tenés basura metida en el directorio de build. Necesitás validación post-extracción, no solo exit codes. Error 3: Instalar gtar pero seguir usando tar en los scripts. Después de brew install gnu-tar, en macOS el binario se llama gtar, no tar. Si seguís escribiendo tar en el script de build, seguís usando BSD tar. Lo hice durante una semana. Este override de PATH es lo que terminé usando para mantener los scripts existentes sin modificarlos. Después de validar los tres casos, mi pipeline de build en macOS quedó así: Y en el Dockerfile de Railway, el paso de extracción tiene su propia verificación: Esta doble verificación — en el momento de crear y en el momento de extraer — es lo que me da confianza real. No confío en que el proceso siempre sea perfecto; confío en que si falla, lo voy a saber antes del deploy y no después. Hace unas semanas escribí sobre mis specs en YAML para agentes y sobre la migración de pgbackrest a Barman. En ambos casos el patrón fue el mismo: una herramienta estándar que "funciona" en la mayoría de los casos, hasta que encuentra el edge case específico de producción. Tar es otro ejemplo de esto. El riesgo real no es que tar sea difícil. Es que tar es tan familiar que nadie lo considera un punto de falla. Cuando el deploy se rompe a las 11pm, nadie piensa "probablemente sea tar". Y eso es exactamente por qué estos bugs duelen más de lo que deberían. ¿Por qué tar en macOS genera archivos ._* y cuándo aparecen?
Los archivos ._nombre son Resource Forks de HFS+/APFS — un mecanismo heredado para almacenar metadata de archivos. Aparecen cuando un archivo tuvo atributos extendidos en algún momento: permisos especiales, metadatos de Finder, etiquetas de color, o simplemente cuando el Finder abrió la carpeta para mostrar previews. No aparecen en todos los archivos; aparecen en los que tocó el sistema de archivos de macOS de cierta manera. Es no-determinístico desde la perspectiva del desarrollador. ¿COPYFILE_DISABLE=1 es suficiente o necesito GNU tar igual?COPYFILE_DISABLE=1 evita que BSD tar incluya metadata extendida en el momento de creación. Es suficiente para el Caso 1 (archivos ._*). Para el Caso 2 (permisos con ACLs) y el Caso 3 (paths con espacios en scripts downstream), necesitás GNU tar y normalización de permisos. En la práctica, uso ambas cosas juntas porque el costo es cero y la combinación cubre más casos. ¿GNU tar en macOS via Homebrew tiene algún tradeoff?El único tradeoff real es que se instala como gtar, no como tar, para no romper el sistema. Si sobreescribís el PATH para que tar apunte a GNU tar, tenés que ser consciente de que algunas herramientas del sistema macOS asumen BSD tar con comportamientos específicos. En la práctica, en 18 meses usando el override de PATH no tuve ningún problema, pero es algo que hay que saber. ¿Esto afecta a GitHub Actions o solo a builds locales?Afecta principalmente a builds locales en macOS y a cualquier runner de CI que corra en macOS. Los runners de GitHub Actions en Ubuntu ya usan GNU tar, así que el problema no aparece ahí. El riesgo real es cuando comprimís en macOS local y subís el artefacto para que un sistema Linux lo extraiga — que es exactamente el workflow de deploy manual o semi-manual. ¿Hay alguna forma de detectar si un tar.gz existente tiene metadata Apple sin extraerlo?Sí, con una línea: Podés incluir esto como validación en el CI antes de publicar el artefacto. ¿Por qué Docker build no protege contra esto?
Docker build copia los archivos al contexto de build, pero si el .tar.gz ya tiene metadata Apple dentro, esa metadata viaja dentro del tar — Docker no inspecciona el contenido del tar al copiarlo. El problema ocurre cuando tu Dockerfile hace RUN tar -xzf y extrae el tar corrupto dentro del contenedor. Docker ve un comando que termina con exit code 0 y asume que todo está bien. GNU tar + COPYFILE_DISABLE=1 + verificación post-extracción resuelve los tres casos. La parte técnica está documentada arriba y podés copiarla en cinco minutos. La trampa real es de actitud: tar es tan viejo y tan familiar que nadie lo agrega a la lista de cosas que pueden fallar. Yo tampoco lo tenía en la lista. Hasta que tuve un deploy roto a las 11pm con logs completamente verdes y media hora mirando código que no tenía ningún error. Si trabajás con Kimi K2, Claude o cualquier LLM para generación de código, ninguno te va a advertir sobre este problema a menos que lo conozcas y lo preguntes explícitamente. Si tu stack toca Railway o cualquier infra containerizada, el problema puede aparecer sin ningún indicador visible. Mi recomendación concreta: auditá los tars que actualmente tenés en producción o en storage con tar -tzf archivo.tar.gz | grep "^\._". Si devuelve resultados, tenés trabajo pendiente. Si no devuelve nada, bien — pero igual agregá la verificación al pipeline para que el próximo build local en macOS no rompa esa garantía silenciosamente. Este es el tipo de problema que aparece en los logs de Railway como síntoma de otra cosa. Y eso es exactamente lo que lo hace caro. Fuente original: Hacker News Este artículo fue publicado originalmente en juanchi.dev Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse
