Ficheros de Mac clásico

Diseño previsto; aún no implementado. Se activa por share con Mac = true.

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.

Almacenamiento: AppleDouble

Sunfish guarda cada fichero de Mac 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.

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

Subir

Por la web o por FTP, en un share con Mac = true:

Llega	Se detecta si…	Se guarda
MacBinary II/III	byte 0 y 74 a cero, longitud de nombre 1–63, longitudes de los forks coherentes y CRC-16 de la cabecera correcto (III: firma `mBIN` en el desplazamiento 102)	`nombre` + `._nombre`
MacBinary I	Sin CRC: solo si la extensión es `.bin` y la cabecera es coherente	`nombre` + `._nombre`
BinHex 4.0	Línea `(This file must be converted with BinHex 4.0)` y CRC de las tres partes correctos	`nombre` + `._nombre`
Cualquier otra cosa	—	tal cual

El nombre se toma de la cabecera (MacRoman → Unicode). Si el fichero no tenía resource fork ni información relevante, no se crea el ._.
Pendiente: opción para conservar además el .bin/.hqx original.

Descargar

En el navegador de directorios de un share con Mac = true, junto a cada fichero aparecen dos enlaces:

[.bin] → fichero?as=macbin, application/x-macbinary, MacBinary III (con CRC, lo leen también los decodificadores de MacBinary II);
[.hqx] → fichero?as=hqx, application/mac-binhex40.

El servidor construye el fichero al vuelo:

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

Por FTP, los clientes de Mac suelen saber codificar y decodificar MacBinary por su cuenta; el servidor solo decodifica lo que se sube (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 previstas

MacBinary I, II y III: decodificar y codificar de ida y vuelta, CRC, falsos positivos (ficheros .bin que no son MacBinary).
BinHex: ida y vuelta, RLE (0x90), líneas de 64 caracteres, CRC.
AppleDouble: lectura y escritura, compatibilidad con los ._ que genera macOS.
Tabla de tipos y nombres MacRoman de 31 caracteres.