# 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](FTP-Y-WEBDAV.md#mac-clásico-por-ftp)).

## 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.