Mappen verdienen beter dan ZIP

Rechtsklikken, ‘Comprimeren’, wachten, bijvoegen, versturen. Dan downloadt de ontvanger, rechtsklikt, ‘Uitpakken’, wacht opnieuw. De meesten van ons doen dit zonder na te denken — zo worden mappen al tientallen jaren verstuurd. Ik vind dat het tijd is om te stoppen met mappen zippen alleen om ze te delen. Het ZIP-formaat stamt uit 1989, toen het probleem was om documenten op diskettes en over trage modems te krijgen. Onze mappen van nu zijn videoprojecten, fotoshoots en coderepositories, en de oude gewoonte kost meer dan ze oplevert.

Waarom zippen we mappen eigenlijk?

Omdat de meeste kanalen om te delen losse bestanden vervoeren. Een e-mailbijlage is een bestand. Een upload in een chat is een bestand. Een klassieke downloadlink wijst naar één bestand. Een map is een boom van bestanden, dus moet hij in één bestand worden verpakt voordat hij door die leidingen past.

Compressie was de tweede reden, en in 1989 deed die ertoe: tekst en spreadsheets worden flink kleiner. Maar voor de meeste mappen die mensen nu versturen, is die reden stilletjes verdwenen.

Wat kost zippen je echt?

Neem een echt voorbeeld: een map van 40 GB van een bruiloftsshoot — RAW-foto's, een paar MP4-clips, wat bewerkte JPEG's.

• Schijfruimte, twee keer. Je hebt ongeveer 40 GB vrij nodig voor het archief naast het origineel. De ontvanger heeft 40 GB nodig voor de ZIP en nog eens 40 GB om hem uit te pakken — 80 GB voor een map van 40 GB, in elk geval tot het archief wordt verwijderd.
• Tijd, drie keer. Jij wacht tijdens het inpakken, dan tijdens de overdracht, en daarna wacht de ontvanger tijdens het uitpakken. Op een laptop kan het in- en uitpakken van tientallen gigabytes even lang duren als de overdracht zelf.
• Bijna geen compressie. JPEG, MP4, MOV en de meeste RAW-formaten zijn al gecomprimeerd. Ze zippen verandert de grootte nauwelijks. Je betaalt de tijd en de schijfruimte en krijgt er bijna niets voor terug.
• Niets is bruikbaar tot het einde. Met één groot archief kan de ontvanger de eerste foto pas openen als de laatste byte binnen is en alles is uitgepakt.

Wat gaat er mis in een ZIP?

Kosten zijn één ding. Er gaan ook dingen mis, en meestal op het slechtst mogelijke moment.

Lange paden. Windows beperkt de volledige lengte van een bestandspad standaard tot 260 tekens. Een projectmap die op een Mac is gemaakt, met diepe submappen en beschrijvende namen, kan op Windows uitpakken met fouten of ontbrekende bestanden.

Enorme archieven. Het oorspronkelijke ZIP-formaat stopt bij 4 GB per bestand en 65.535 items. De uitbreiding ZIP64 haalt die limieten weg, maar niet elke tool op elke machine gaat er op dezelfde manier mee om. Sommige clouddrives splitsen de download van een grote map in meerdere ZIP-bestanden, die de ontvanger daarna weer moet samenvoegen.

Bestandsnamen. Archieven die met de ene tool zijn gemaakt en met een andere worden geopend, kunnen niet-Latijnse bestandsnamen verminken — Cyrillisch, Grieks, Chinees, letters met accenten. De structuur komt aan, de namen niet.

Rommel. Archieven die met de Finder van macOS zijn gemaakt, bevatten mappen __MACOSX en bestanden .DS_Store die Windows-gebruikers in verwarring brengen en in het project van de ontvanger terechtkomen.

Eén fout, opnieuw beginnen. Mislukt een download van 40 GB op 95 %, dan is het archief onbruikbaar. Is er één byte beschadigd, dan kan het uitpakken halverwege stoppen.

Niets hiervan is exotisch. Heb je ooit een map van meer dan een paar gigabyte verstuurd, dan ben je waarschijnlijk minstens een van deze problemen tegengekomen.

Hoe verstuurt StrongFolder een map als map?

We hebben StrongFolder gebouwd op een eenvoudig idee: als de bestanden rechtstreeks van jouw browser naar die van de ontvanger gaan, is er geen reden om ze eerst in één bestand te verpakken.

Als je een map kiest, leest je browser de structuur — elke submap en elke bestandsnaam. Er wordt niets geüpload. Je verstuurt de link; de ontvanger opent hem en kiest waar hij wordt opgeslagen. Daarna reizen de bestanden rechtstreeks tussen de twee browsers via een versleutelde WebRTC-verbinding, elk met zijn relatieve pad, en verschijnt dezelfde mappenstructuur op de schijf van de ontvanger.

Wat dit in de praktijk verandert:

• Niet inpakken, niet uitpakken. De overdracht begint op het moment dat de ontvanger de link opent.
• Geen extra schijfruimte. De ontvanger heeft ruimte nodig voor de map, niet voor de map plus een archief.
• Bestanden komen één voor één aan. De eerste foto's staan al op de schijf van de ontvanger terwijl de rest nog onderweg is.
• Paden worden eerlijk behandeld. Is een pad te lang voor Windows, dan korten we de naam in en voegen we een tekstbestand toe met alle hernoemde bestanden. Er verdwijnt niets stilletjes.
• Geen limiet van onze kant. StrongFolder stelt geen groottelimiet. De praktische grenzen zijn de vrije schijfruimte op het apparaat van de ontvanger, de verbindingssnelheid en hoe lang beide apparaten online blijven.

Er zijn twee voorwaarden die ik altijd noem. Om een hele map met structuur op te slaan heeft de ontvanger Chrome, Edge, Opera of een andere Chromium-browser op een computer nodig — andere browsers downloaden de bestanden één voor één of als ZIP. En je tabblad moet open blijven tot de ontvanger klaar is, want de bestanden komen van jouw apparaat, niet van een server. Dat is de prijs van niets uploaden. Waarom de verzender online blijft legt het uitgebreid uit.

Wanneer is een ZIP nog steeds het juiste gereedschap?

Ik ben niet tegen ZIP. Het is een uitstekend formaat — alleen niet als standaardstap vóór elke verzending. Ik zip nog steeds als:

• ik archiveer. Eén bestand is makkelijker op te slaan, te controleren met een checksum en jaren te bewaren.
• ik een wachtwoord nodig heb. Links van StrongFolder hebben geen wachtwoord. Voor gevoelige bestanden voegt een versleuteld archief (bijvoorbeeld 7-Zip met AES-256) plus een wachtwoord via een ander kanaal een laag toe die met elke overdrachtsmethode werkt.
• de map uit tienduizenden piepkleine bestanden bestaat. Een map node_modules of een cache met kleine afbeeldingen gaat sneller als één bestand, omdat elk bestand zijn eigen overhead heeft.
• de ontvanger op een telefoon zit. Telefoons kunnen vanuit een browser geen mappenstructuur opslaan, dus de bestanden komen toch één voor één of als ZIP.

Voor al het andere — de shoot, de montage, het CAD-project, de gamemod, het gescande archief — verstuur je de map zoals hij is.

Hoe stop je voorgoed met mappen zippen?

Wil je de stap-voor-stap-versie, met e-mail, clouddrives en overdrachtsdiensten naast elkaar vergeleken, lees dan Een map versturen zonder te zippen. Voor heel grote mappen behandelt Grote bestanden versturen snelheid en instellingen, en Limieten en vereisten noemt elk detail per browser.

En komt een map ooit kapot aan — verkeerde namen, ontbrekende submappen, wat dan ook — schrijf me dan via info@strongfolder.com. Mappen zijn de reden dat StrongFolder bestaat, en ik wil het weten.