Ficheros de Mac clásico

Implementado (fase 6). Funciona de forma transparente en todos los shares; Mac = false lo desactiva en un share concreto.

El problema

En Mac OS clásico (System 6 a Mac OS 9) un fichero tiene:

• Data fork: el contenido "normal".
• Resource fork: recursos. En aplicaciones y muchos documentos es imprescindible.
• Información del Finder: tipo y creador (4 caracteres cada uno), indicadores, posición.

Windows y Linux solo guardan el data fork. Si un fichero de Mac pasa por un servidor normal, pierde el resto y deja de funcionar. Por eso en esa época se viajaba codificado:

• MacBinary (.bin): binario, una cabecera de 128 bytes y después los dos forks.
• BinHex 4.0 (.hqx): texto de 7 bits, apto incluso para correo.

Por qué puede ser transparente

• Detectar MacBinary II/III y BinHex es fiable, porque llevan CRC: un fichero que no lo es prácticamente nunca pasa la comprobación por casualidad.
• El fichero decodificado se puede volver a codificar sin pérdida: el data fork queda como fichero normal y el resto se guarda aparte.
• Si el fichero no tiene nada propio de Mac, no se toca.

Por eso no hace falta activarlo. Mac = false solo tiene sentido en shares que guardan .bin/.hqx como archivo (p. ej. una colección de software para emuladores), donde se quiere conservar el fichero codificado tal cual.

Almacenamiento: AppleDouble

Cada fichero de Mac se guarda como:

• nombre: el data fork, usable desde cualquier sistema;
• ._nombre: fichero AppleDouble (versión 2) en la misma carpeta, con la entrada 9 (Finder Info, 32 bytes) y la entrada 2 (Resource Fork).

Es el mismo formato que usa macOS en volúmenes que no admiten forks (FAT, SMB…), así que es compatible con macOS moderno y con otras herramientas.

• Los ._* que acompañan a un fichero, .DS_Store e Icon\r no se muestran en los listados (web, FTP, WebDAV).
• Renombrar, mover o borrar un fichero hace lo mismo con su ._.

Subir

Por formulario web, por la subida por trozos de la página moderna (PUT con X-Sunfish-Upload) o por FTP (STOR):

• El nombre se toma de la cabecera (MacRoman → Unicode).
• Si el fichero no tenía resource fork ni información relevante del Finder, no se crea el ._.
• Si el nombre decodificado ya existe y el share no tiene Overwrite, se conserva el fichero codificado tal como llegó (no se pierde nada) y el registro lo avisa. Con Overwrite, se sustituye.
• Un PUT de WebDAV normal no se decodifica: los clientes WebDAV modernos (Finder, Windows) ya escriben los forks como ._ por su cuenta, y un .bin copiado así se quiere tal cual.
• BinHex se decodifica en memoria: solo hasta 256 MB.

Descargar

• Cliente con perfil mac (CLIENTES.md), fichero con ._: la descarga normal se entrega en MacBinary automáticamente (application/x-macbinary). El decodificador del navegador (o el que tenga asociado) restaura los forks sin que el usuario haga nada.
• Cliente con perfil mac, fichero sin ._: se entrega tal cual. El Mac asigna tipo y creador por su tabla de extensiones.
• Cualquier otro cliente: recibe el data fork. Si el fichero tiene ._, el listado lo marca y ofrece enlaces explícitos:
  • [.bin] → fichero?as=macbin, MacBinary III (también lo leen los decodificadores de MacBinary II);
  • [.hqx] → fichero?as=hqx, application/mac-binhex40.

Al codificar:

• data fork = el fichero; resource fork e información del Finder = su ._;
• si no hay ._ (enlaces explícitos), tipo y creador salen de una tabla por extensión (p. ej. .txt → TEXT, .gif → GIFf, .jpg → JPEG, .sit → SIT!, .pdf → PDF). Pendiente: ampliarla con una sección [MacTypes] en la configuración (aún no existe);
• el nombre se convierte a MacRoman y se acorta a 31 caracteres (límite de HFS), conservando la extensión.

Para FTP, ver FTP-Y-WEBDAV.md.

Fuera de alcance

• StuffIt (.sit) y otros formatos comprimidos de Mac: se tratan como ficheros normales.
• Conversión de saltos de línea CR de los ficheros de texto de Mac (lo hace el cliente o el modo TYPE A de FTP).

Pruebas

En tests/Sunfish.Tests/MacTests.cs:

• MacBinary III de ida y vuelta (forks, tipo, creador, fecha), CRC alterado y falsos positivos (datos aleatorios, un .bin cualquiera queda intacto).
• BinHex de ida y vuelta con bytes 0x90 (RLE) y CRC alterado.
• AppleDouble de ida y vuelta; el ._ sigue al fichero al mover y borrar.
• Decodificación al subir y conservación del codificado si el nombre ya existe.
• Servidor real: enlaces [.bin]/[.hqx], ?as=macbin/?as=hqx, entrega automática al perfil mac, subida por formulario que se decodifica, FTP +mac (nombre.bin en el listado, SIZE, RETR, STOR que se decodifica).
• Probado también con el binario AOT: subida MacBinary por FTP, separación en nombre + ._nombre y descarga .bin idéntica byte a byte.
• Sin probar con un Mac clásico real ni con ._ generados por macOS moderno.