Cross-platform file transfer

Windows, macOS, and Linux will all store the bytes. They will not all agree what a filename, a fork, or a text line means. RFC 959 made this explicit for FTP: ASCII mode may translate line endings, image mode copies bytes unchanged. Sending a ZIP in ASCII mode corrupts it. The protocol still reports success.

The failures are concrete. A macOS client writes `._notes.txt` AppleDouble sidecars and a `.DS_Store` beside the real files. A Windows client rejects a trailing period or a name with a colon. A Linux server is case-sensitive, so `Cut.mov` and `cut.mov` are two objects and a Windows download folder quietly collides them. Resource forks and alternate data streams do not survive a bucket PUT unless someone packed them. HTTPS, per RFC 9110, preserves the body you sent. It does not preserve filesystem metadata you forgot to send.

A designer on a Mac uploads a folder of 200 assets through the browser. The ZIP they made with the default tool includes `__MACOSX/`. The Windows editor unzips, opens a sidecar by mistake, and says the file is corrupt. A second run zips without AppleDouble, uses image-safe binary, and publishes a SHA-256 of the archive. The editor's hash matches. The pictures open. SFTP in binary mode would have done the same for a single file. It would not have stripped the sidecar unless the packager did.

Cross-platform does not mean a special protocol. It means you picked a byte-preserving channel, a packager both sides open, and a checksum. AirDrop and a nearby share are same-vendor shortcuts. They are not this term once the other side is a different operating system.