Het komt niet vaak voor dat lezers hun TidBITS-afleveringen willen afdrukken, dus ik was enigszins verbaasd toen Lauri Reinhardt, die ons helpt bij ondersteuning, me een bericht van een lezer doorstuurde waarin werd gevraagd of er een manier was om de e-mailversie van TidBITS af te drukken inclusief afbeeldingen. We hadden dit beiden nog noog geprobeerd maar deze lezer had wel gelijk: als je een TidBITS-aflevering afdrukt of exporteert naar PDF krijg je lege vlakken in plaats van de beoogde afbeeldingen. 

Verschillende instellingen in de Privacybescherming in Mail-voorkeuren van Mail maakten geen verschil en de afbeeldingen waren altijd gewoon zichtbaar in het feitelijke e-mailbericht — het probleem was duidelijk niet het binnenhalen van de informatie van de server. Wat nog verwarrender was was dat Mimestream, dat ik met Gmail gebruik, het probleem ook had maar alleen in macOS 12 Monterey, niet in macOS 13 Ventura. Afdrukken vanuit de web-interface van Gmail vertoonde het probleem ook niet.

Een blik op de broncode van onze afleveringen liet al snel een voor de hand liggende oorzaak zien: een instelling loading="lazy" bij elke IMG-tag in onze artikelen. De sponsor-advertenties bovenaan een aflevering hebben die instelling niet en die komen dan ook gewoon correct in een PDF terecht. Mijn nieuwsgierigheid was gewekt en ik nam contact op met de ontwikkelaar van Mimestream, Neil Jhaveri, die in het verleden bij Apple aan Mail had gewerkt. Hij meldde dat Mail een webview in geheugen creëert, wacht totdat het “load” deel van een document binnenkomt, waarna het wordt afgedrukt. Maar loading="lazy" laad afbeeldingen alleen als ze werkelijk een venster in gescrolld worden en dat gebeurt dus nooit bij een printopdracht. Mimestream heeft hetzelfde probleem, in elk geval in Monterey, omdat het WebKit gebruikt om af te drukken, net als Mail. Neil raadde aan om de loading="lazy"-instelling niet meer te gebruiken, omdat volgens hem afbeeldingen (in elk geval afbeeldingen met width- en height-instellingen) er sowieso voor zorgen dat een pagina pas wordt gerendered als de afbeeldingen geladen zijn.

Tijdens deze gesprekken stuitte Lauri op een oplossing die logisch is in de context van Neils uitleg. Ze veronderstelde dat de afbeeldingen misschien te groot waren om te laden, dus probeerde ze ze te verkleinen met de schalingsoptie in het dialoogvenster "Druk af...", waardoor er in ieder geval enkele afbeeldingen werden weergegeven. Ik heb getest en ontdekte dat als ik het schaalpercentage wijzigde in 99%, sommige afbeeldingen werden geladen maar ze waren vaag, en andere bleven leeg. Als ik het schaalpercentage echter drastischer wijzigde, bijvoorbeeld naar 87%, en vervolgens door het volledige documentvoorbeeld ging scrollen, alle afbeeldingen haarscherp in de resulterende pdf verschenen, zelfs als ik de schaal later terugzette naar 100%. Vermoedelijk dwong het vragen aan het afdrukdialoogvenster om de uitvoer te schalen, WebKit om alle afbeeldingen te laden, zodat ze konden verschijnen.

Toen ik onze ontwikkelaar Eli Van Zoeren vroeg om dat loading="lazy"-attribuut uit de IMG-tags te verwijderen, merkte hij op dat WordPress het automatisch heeft ingevoegd, dus voegde hij een filter toe om het uit de e-mailversies van onze uitgaven te verwijderen. (Zijn code voegt de sponsorbanners afzonderlijk toe aan de uitgave en daarom missen ze dat kenmerk.) Ik was opgewonden om de oplossing te testen met het nummer van de week daarna maar tot mijn teleurstelling ontdekte ik dat het probleem niet was verdwenen. Het bleek dat, nadat Eli loading="lazy" eruit had gefilterd, WordPress het verving door een soortgelijk klinkend attribuut decoding="async". Na nog een rondje attribuut meppen, was het probleem voorgoed verdwenen.

Dus hoewel ik het afdrukken van TidBITS-uitgaven niet aanraad, we formatteren ze niet voor afdrukken en ze verbruiken nogal wat papier, zul je nu in ieder geval de afbeeldingen zien. Interessant is dat beide bovenstaande schermafbeeldingen aan het einde extra blanco pagina's hebben. Ik weet niet waarom Mail die toevoegt, maar ik raad aan ze te verwijderen. Kies "Archief > Exporteer als pdf", open het bestand in Voorvertoning, selecteer de lege pagina's (en eventuele andere onnodige pagina's) in de navigatiekolom en verwijder ze voordat je ze afdrukt.

Ik betwijfel ten zeerste of veel mensen door dit probleem zijn getroffen maar tenminste één TidBITS-lezer zal gelukkiger zijn, en met een beetje geluk zullen anderen die tegen een soortgelijk probleem aanlopen dit artikel vinden en ontdekken hoe ze het sneller kunnen oplossen.

Het afgelopen jaar zijn cloudopslagdiensten Box, Dropbox, Google Drive en Microsoft OneDrive (en waarschijnlijk ook andere) gemigreerd van eigen kernel-extensies naar de min of meer nieuwe File Provider-extensie van Apple. Deze biedt een door Apple goedgekeurd raamwerk om bestanden op afstand in macOS te integreren en in de Finder weer te geven. Ik besprak deze stap een jaar geleden in “Voorspelling voor cloudopslag: wisselvallig, mogelijk storm” (4 februari 2022).

De File Provider-extensie verscheen voor het eerst in macOS 12.1 Monterey, hoewel de Developer-site van Apple suggereert dat het daarna mogelijk beschikbaar is gemaakt in macOS 10.15 Catalina. Eerdere versies van macOS ondersteunen het niet, dus er verandert voorlopig niets voor mensen met oudere systemen. De cloudopslagdiensten zullen waarschijnlijk op een gegeven moment de ondersteuning voor oudere systemen intrekken, maar het is niet te zeggen wanneer dat zal gebeuren. (Alles wat ik hieronder zeg heb ik getest in macOS 13.2.1 Ventura, het is mogelijk, zelfs waarschijnlijk, dat sommige details anders zijn in Monterey).

De cloudopslagbedrijven vonden ongetwijfeld dat ze weinig keus hadden om de File Provider-extensie over te nemen, omdat Apple zei dat het op een gegeven moment kernelextensies zou afschaffen. Dat is nog niet gebeurd, maar Apple geeft ontwikkelaars vaak enkele jaren de tijd om mee te werken.

Ik heb begrepen dat Box, Google en Microsoft hun Mac-gebruikers hebben gemigreerd naar de File Provider-aanpak, terwijl Dropbox (waarschijnlijk de populairste onder gewone Mac-gebruikers), pas onlangs is begonnen met het aanmoedigen van mensen buiten het bètaprogramma om over te stappen (terwijl anderen nog steeds worden gevraagd om mee te doen met de bèta). Het is moeilijk te zeggen, omdat aanbieders van cloudopslag veranderingen vaak gespreid of aan deelgroepen van klanten uitrollen om de reactie van gebruikers te testen, problemen op te sporen en de ondersteuningsbelasting te verminderen. Sommige Dropbox-gebruikers melden zelfs dat een van hun Macs werd geüpgraded naar de nieuwe File Provider-aanpak, terwijl andere de kernel-extensie blijven gebruiken.

Hoewel het goed is dat cloudopslag op een coherente manier in macOS is geïntegreerd, brengt de overstap naar de File Provider-extensie van Apple twee belangrijke veranderingen met zich mee die aanpassingen zullen vergen in hoe je werkt.

De eerste verandering is waar lokale bestanden worden opgeslagen. Alle cloud-opslagdiensten moeten hun bestanden nu opslaan in ~/Library/CloudStorage. (Dat is in de bibliotheekmap van je thuismap, die voor de meeste gebruikers moeilijk toegankelijk is omdat de bibliotheekmap standaard verborgen is). Vanuit het oogpunt van consistentie en coherentie is de nieuwe standaardlocatie een goede zaak, omdat gebruikers niet hoeven bij te houden waar elke afzonderlijke dienst zijn bestanden heeft staan. Maar net als bij de introductie van de thuismap in Mac OS X en de nu gebruikelijke submappen (Bureaublad, Documenten, Bibliotheek, Films, Muziek, enz.) zal het verlies aan flexibiliteit voor sommige gebruikers pijnpunten opleveren.

De tweede verandering betreft de vraag of de bestanden zowel lokaal als online bestaan ("offline" of "pinned") of alleen online ("online-only"). Beide hebben voor- en nadelen:

• Offline bestanden worden zowel in de cloud als op de lokale schijf opgeslagen voor snelle toegang. Ze verbruiken echter lokale opslagruimte, wat een probleem kan zijn als je weinig vrije ruimte hebt. Er is geen zichtbare indicatie dat een bestand een offline bestand is.
• Alleen-online bestanden bestaan lokaal alleen als pictogrammen totdat ze worden geopend. Ze hebben kleine wolk-pictogrammen naast hun naam in de Finder. Deze aanpak bespaart ruimte, maar kan lijden onder vertragingen bij het laden van grote bestanden of langzame verbindingen. Natuurlijk zijn alleen-online bestanden niet beschikbaar als je geen verbinding hebt.
  

Als je voor het eerst een cloudopslagdienst migreert naar de File Provider-benadering, ga er dan vanuit dat al je bestanden en mappen alleen online zijn. Dat is misschien niet het geval, je kan het zien aan de kleine wolkpictogrammen, maar dergelijke bestanden kunnen, zoals ik hieronder zal bespreken, niet worden bekeken met Snelle weergave, geïndexeerd door Spotlight of geback-upt met Time Machine en andere back-up-apps.

Je kan de status van elk bestand of elke map controleren. Als je op het wolkenpictogram naast de naam van een bestand of map klikt, start dat een download en verandert het van alleen-online naar offline. Control-klik op een offline bestand en je vindt opdrachten om bestanden te downloaden (ze offline te maken) of de downloads ervan te verwijderen (ze alleen-online te maken). Dropbox (linksonder) gebruikt de opdrachten “Make Available Offline” en “Make Online-Only” in het gedeelte Snelle acties onderaan het pop-upmenu. Google Drive (rechtsonder) plaatst de opdrachten “Download Now” en “Remove Download” bovenaan het menu; het heeft ook Snelle acties.

Bij het openen van een alleen-online bestand wordt dit natuurlijk ook gedownload. Het is mogelijk dat een app van derden niet blij is als het iets moet met een bestand dat nog niet gedownload is; als je een foutmelding krijgt, zorg er dan voor dat het bestand offline beschikbaar is en probeer opnieuw.

Laat het duidelijk zijn dat dit onderscheid tussen offline en alleen-online bestanden niet nieuw of uniek is aan voor File Provider-extensie. Alle cloudopslag-diensten hebben altijd manieren geboden om aan te geven welke bestanden of mappen lokaal moesten worden bewaard en welke alleen online stonden. De details en implicaties waren misschien net even anders, maar het concept was hetzelfde.

Laten we eens kijken naar een aantal consequenties van deze veranderingen door File Provider. Ik bespreek hieronder Dropbox en Google Drive omdat dat de diensten zijn die ik zelf regelmatig gebruik, maar Box en OneDrive zouden in de meeste gevallen ook zo moeten werken.

Plaats in de navigatiekolom kan veranderen

De aanpak van File Provider trekt cloudopslag-diensten gelijk met elkaar en met andere vormen van opslag in macOS. Als gevolg hiervan heeft Apple besloten dat deze standaard in de navigatiekolom van het Finder-venster verschijnen onder Locaties. Je kunt ze zelfs allemaal aan- of uitzetten onder Finder > Voorkeuren/Instellingen > Navigatiekolom.

De nieuwe plek kan wat verwarring opleveren als je het Locaties-onderdeel in de navigatiekolom voorheen dicht had staan of Dropbox of Google Drive doorgaans opende vanuit de navigatiekolom onder Favorieten. Je kunt echter altijd het navigatiekolom-onderdeel van een cloudopslag-dienst van Locaties naar Favorieten slepen of deze zelfs onder zowel Locaties als Favorieten hebben staan.

Deze verandering is klein en snel aangepast naar jouw wensen, maar ik noem het vooral omdat je op de navigatiekolom-onderdelen die je hebt zou moeten klikken om te controleren of die nog steeds (goed) werken.

Pas op voor ontkoppelde lokale mappen

In welk geval kan een navigatiekolom-onderdeel niet naar de juiste plek verwijzen? Als een cloudopslag-dienst van hun eigen kernel-extensie overstapt naar de File Provider-extensie, verandert de locatie van de lokale map van waar je die had ingesteld naar ~/Bibliotheek/CloudStorage. Dat is tenminste de bedoeling.

(Om je geheugen even op te frissen: als je de map Bibliotheek niet in je thuismap ziet, houd dan de optie-knop ingedrukt terwijl je het Ga-menu kiest, Bibliotheek wordt dan in het menu zichtbaar. Je kunt ook, met de thuismap open, Weergave > Toon weergaveopties kiezen en vervolgens Toon bibliotheekmap selecteren, zodat de map altijd zichtbaar is.)

Sommige gebruikers, wij ook, zijn situaties tegengekomen waarbij de lokale map niet verhuist maar van de dienst losgekoppeld wordt. Omdat de cloud-opslagdienst meteen naar de nieuwe locatie zal synchroniseren, zou het kunnen zijn dat je twee Dropbox-mappen ziet, bijvoorbeeld één in ~/Dropbox en een andere in ~/Library/CloudStorage/Dropbox.

De cloud-opslagdiensten zaaien verwarring door in de oude locatie iets aan te maken wat op een alias lijkt (maar eigenlijk een symbolische koppeling is) om de continuïteit voor gebruikers te waarborgen. Maar is die Dropbox-map in je thuismap nu een symbolische koppeling of een losgekoppelde lokale map? Je kunt dit controleren door Terminal te openen en ls -l in te typen (als je nog niet in je thuismap bent, gebruik dan eerst het commando cd). Zoals je hieronder kunt zien, staan er nu symbolische koppelingen naar mappen van Dropbox en Google Drive in mijn thuismap. Kijk maar eens hoe de symbolische koppelingen in de meest linkse kolom een l hebben, terwijl mappen zoals Downloads en Bibliotheek met een d beginnen en de Dropbox Demo Alias die ik voor afbeeldingen aangemaakt heb een - heeft.

Controleer je bevindingen door een nieuw bestand naar de lokale map te kopiëren en daarna op de website van de cloud-opslagdienst te checken of het bestand is geüpload.

Als je een losgekoppelde lokale map hebt, dan zul je steekproefgewijs wat controles uit moeten voeren om er zeker van te zijn dat alles in de map ook in de online versie staat. Ik doe dit door lijstweergave in de Finder te gebruiken, op bewerkingsdatum te sorteren en vervolgens de mappen te openen en te controleren of de recentste bestanden ook op beide plaatsen staan. Toen ik dit tegenkwam bij Google Drive, had ik slechts een klein aantal bestanden die niet goed gesynchroniseerd waren. Als je veel verschillen ziet, zou je kunnen overwegen om synchronisatiesoftware zoals ChronoSync te gebruiken om erachter te komen welke bestanden verplaatst moeten worden.

Verwijder de lokale map als je klaar bent, om te voorkomen je dat je hem per ongeluk later nog een keer gebruikt. Als de dienst vervolgens niet automatisch een symbolische koppeling voor je aanmaakt, raad ik je aan om er zelf een te maken via de volgende stappen:

1. In Terminal: typ cd en druk op Return om er zeker van te zijn dat je in je thuismap bent.
2. Typ ln -s  (met een spatie na de s).
3. In de Finder: kies Ga > Ga naar map, typ ~/Library/CloudStorage en druk op Return om die map te openen.
   
4. Sleep de map van de cloud-opslagdienst (bijvoorbeeld Dropbox of Google Drive) van de Finder naar het Terminal-venster om het pad toe te voegen. Deze aanpak is noodzakelijk omdat in ieder geval Google Drive een andere naam hanteert dan die je ziet. Druk op Return om een symbolische koppeling aan te maken.
   

Verwijzingen naar lokale bestanden en mappen kunnen ongeldig worden

In een ideale wereld zal de cloud-opslagdienst een alias van de verplaatste lokale map vanuit ~/Library/CloudStorage aanmaken op de plaats waar die voorheen stond en zullen aliassen of andere verwijzingen naar bestanden of mappen in die map moeten blijven functioneren.

Dat is echter niet altijd het geval, zeker als je een losgekoppelde map hebt opgeruimd. Als je de losgekoppelde lokale map hebt verwijderd, zoals ik aanraadde, zullen aliassen die naar bestanden of mappen verwezen, niet langer geldig zijn. Dat is goed, want dan weet je dat je ze opnieuw aan moet maken.

Op eenzelfde manier hebben apps zoals BBEdit, Keyboard Maestro en Transmit de mogelijkheid om ondersteuningsbestanden in cloud-opslag te bewaren als een manier om instellingen en andere gegevens tussen Macs te synchroniseren. In de bovenbeschreven ideale wereld zou alles goed moeten blijven functioneren en dat was ook mijn ervaring met de recentste Dropbox-migratie van een paar Keyboard Maestro-macro’s die verwijzen naar Automator-workflows en BBEdit-tekstfilters die ik in Dropbox had bewaard.

Er zijn echter geen garanties dat verwijzingen naar bestanden allemaal naar de nieuwe locaties zullen worden overgezet, en in het geval van apps die cloud-opslag gebruiken om instellingen te synchroniseren, kan het zijn dat je het niet meteen doorhebt. Kijk voor tips over welke apps wellicht cloud-opslag aanwenden voor synchronisatie in je cloud-opslagmappen, met name Dropbox.

Ondersteuning voor externe schijven verdwijnt, behalve bij OneDrive

De opvallendste beperking van de nieuwe benadering met File Provider is dat ~/Library/CloudStorage zich op je interne schijf bevindt. Voor mensen met terabytes aan bestanden bij een dienst voor cloud-opslag is dat een groot probleem.

Voorheen kon je instellen waar je de lokale map van je clouddienst wilde hebben staan, waardoor je hem makkelijk op een grote externe schijf kon plaatsen. Met File Provider kan dat niet langer. Tenminste, dat zeggen Box, Dropbox en Google op dit moment, hoewel Microsoft in OneDrive het probleem omzeilt door de “sync root” (die in ~/Library/CloudStorage moet staan) te scheiden van de cache, die wel op een externe schijf kan staan.

Gebruikers maken zich hier boos over, vooral mensen die Dropbox gebruiken om computers die zij gebruiken voor audio- en videoverwerking up-to-date te houden met grote gedeelde bestanden.

Er is niet alleen slecht nieuws. Op 17 februari 2023 plaatste Dropbox een bericht in een lange en giftige discussie over het verlies van ondersteuning voor externe schijven, en Dropbox zei in dat bericht dat het bedrijf aan een oplossing werkte en gebruikers in de tussentijd niet verplichtte om bij te werken als men gebruikmaakte van een map op een externe schijf.

Als het wachten op een oplossing van Dropbox geen optie is zou je de open source Dropbox-client Maestral kunnen overwegen. Deze stelt je in staat om je Dropbox-map waar dan ook te plaatsen, dus ook op een externe schijf. Maestral gebruikt de publieke Dropbox API, waardoor het niet slechts die onderdelen van een bestand kan verplaatsen die veranderd zijn. In plaats daarvan moet Maestral gehele bestanden verplaatsen, wat langzamer is en meer bandbreedte verbruikt. Maestral telt verder niet mee in de beperking van drie apparaten in een basic account. (Zie “Dropbox beperkt gratis accounts tot drie apparaten”, 14 maart 2019.)

Er is misschien nog een andere oplossing, en die is je hele thuismap verplaatsen naar een externe schijf. Control-klik op een gebruiker in Systeemvoorkeuren/Instellingen > Gebruikers en groepen om bij het veld Thuismap te komen. Doe dit alleen als je technisch onderlegd bent en weet wat je doet, en maak eerst meerdere back-ups.

Zelfs als het verplaatsen van de thuismap werkt zoals je wil, heeft het nadelen. Het werkt natuurlijk niet goed voor laptops, en als je niet bereid bent om te investeren in een dure SSD heb je te maken met de lagere snelheid van de ingebouwde schijf. Verder is er ook wat discussie online over dat het installeren van macOS-updates terwijl je ingelogd bent op een account op een externe schijf problemen kan veroorzaken. De consensus lijkt te zijn om macOS bij te werken vanaf een beheerdersaccount dat wel op een interne schijf staat. Als jij dit doet horen we graag hoe dit werkt.

Als je van een beetje spanning houdt en genoeg technische bagage en uitstekende back-ups hebt, zijn er nog andere mogelijkheden. Ook dan horen we graag of deze mogelijkheden werken:

• Dropbox: als je al bent overgestapt op de nieuwe File Provider benadering van Dropbox heb je mogelijk iets aan de oplossing van een gebruiker in een andere draad in de Dropbox Community. Je gebruikt dan een symbolische koppeling die naar de Dropbox-map op een externe schijf verwijst, vergelijkbaar met wat Microsoft doet met OneDrive. In het recente verleden ondersteunde Dropbox geen symbolische koppelingen naar onderdelen op externe schijven, maar dat is misschien veranderd.

• Google Drive: hoewel Google Drive beweert dat je de locatie niet kan veranderen, wordt er in een draad van mei 2022 op het Google Drive Help forum aanbevolen om het Unix-commando touch te gebruiken om een bestand op een bepaalde locatie aan te maken. De suggestie is dat hiermee de app Google Drive zich gaat gedragen zoals in het pre-File Provider-tijdperk.

Bij verslepen worden bestanden verplaatst in plaats van gekopieerd

Sommige cloud-opslagdiensten gebruikten hun kernel extensions om hun lokale map als een apart volume te zien. Dit betekende in de praktijk dat als je een bestand naar of vanuit de lokale map van zo'n dienst sleepte het bestand werd gekopieerd, waarbij het origineel gewoon op zijn oude plek bleef en er een aparte kopie op de doellocatie gemaakt werd. Je kunt erover twisten of dit wenselijk was, maar feit is dat gebruikers hieraan gewend raakten.

Met de aanpak van File Provider zijn alle cloud-opslagdiensten de facto mappen op de interne harde schijf, geen aparte volumes, en dus resulteert het slepen van een bestand van je Bureaublad naar je Dropbox-map in het verplaatsen van het bestand, niet het kopiëren ervan. Zo ook het slepen van een bestand van Google Drive naar je Bureaublad.

Dat is een majeure wijziging, omdat deze diensten ook een online versie van het bestand moeten bewaren, waardoor in elk geval Dropbox en Google Drive het verplaatsen van een bestand naar een andere map in de Finder interpreteren als het verwijderen van de online versie, waarbij het verplaatste bestand in de online prullenbak van de dienst wordt geplaatst. Beide diensten laten je weten wat er gebeurt, en je kunt die meldingen uitzetten.

Bij verwijderen van een bestand blijft de online versie staan, maar het verschilt per clouddienst

Wat gebeurt er als je in Finder een bestand verwijdert uit een cloud-opslagdienst? Dat verschilt. Zelf kan ik alleen zien hoe het bij Dropbox en Google Drive werkt, maar ik denk dat het bij Box en OneDrive ook op een van deze manieren gaat. Als je zelf constateert dat deze aanname niet klopt, licht dan jouw observaties toe in de reacties hieronder.

Bij Dropbox zie hangt het gedrag ervan af of het bestand ook offline of alleen online bestaat. Als je een offline bestand verwijdert, dan wordt het gewoon naar de Prullenmand verplaatst, zoals dat werkt met ieder ander bestand. Je kunt het terugzetten, naar een andere locatie verplaatsen of permanent verwijderen door de Prullenmand te legen. Als je daarentegen een bestand verwijdert dan alleen online bestaat, dan waarschuwt Dropbox je dat het bestand onmiddellijk permanent verwijderd wordt. (Zie linksonder.) Als Dropbox zegt dat de actie niet teruggedraaid kan worden, dan zal het bestand ook niet in jouw lokale Prullenmand gezet worden. De herstel-actie commando-Z werkt dan ook niet. Maar let op: beide verwijder-acties hierboven betekenen wel dat het bestand door Dropbox in de map Deleted Files op Dropbox' website gezet wordt. Daar blijft het nog 30 dagen staan alvorens definitief verwijderd te worden. (Zie rechtsonder.)

In Google Drive bestaat een dergelijk onderscheid niet. Als je willekeurig welk bestand in Google Drive verwijdert (of het nu offline bestaat of alleen online), dan wordt het, precies zoals elk ander bestand, altijd in jouw lokale Prullenmand gezet. Je kunt werken met commando-Z om het verwijderen terug te draaien. Bestanden die alleen online bestaan zie je in Finder nog steeds met een cloud-symbool ernaast, maar dan in de Prullenmand. Net als Dropbox zet ook Google Drive de verwijderde bestanden in zijn online Prullenmand. Zie in de schermafbeeldingen hieronder de twee verwijderde ChartOfAccounts-bestanden. Ook Google Drive bewaart bestanden 30 dagen online.

Zoekopdrachten kunnen minder goed werken voor informatie in de Cloud

De offline- of alleen-onlinestatus van bestanden heeft consequenties voor zoekopdrachten. Een bestand dat alleen online bestaat is uiteraard niet beschikbaar voor indexering door Spotlight. Het zoeken naar bestandsnamen in de Finder zou echter gewoon moeten werken, net als zoekopdrachten in hulpprogramma's van derden, zoals EasyFind of Find Any File.

Google Drive biedt een eenvoudige oplossing voor zoekopdrachten op inhoud. Je kunt een speciaal Google Drive-zoekvenster openen in de Finder: de standaard toetscombinatie hiervoor is commando-optie-G. Dit commando voert een zoekopdracht uit in Google Drive op het web, waarmee de inhoud van je bestanden op Google Drive wél doorzocht kan worden. Het kan ook zoeken in Google Docs en Google Sheets, zaken die sowieso nooit in Spotlight gevonden zouden worden, omdat ze op lokale schijven uitsluitend als verwijzingen naar online gegevens aanwezig zijn.

Back-ups werken, maar…

Inmiddels kun je zien dat bestanden die alleen online staan niet echt op je Mac bestaan. Dat betekent dat Time Machine en andere back-upoplossingen er geen back-up van kunnen maken. Het lijkt alsof alle Dropbox- mappen verschijnen in Time Machine, hoewel er alleen offline bestanden in te vinden zijn. De mappen van Google Drive verschijnen daarentegen alleen als ze offline bestanden bevatten. Evenzo ziet Backblaze offline bestanden in ~/Library/CloudStorage, en maakt het er een back-up van, maar het weet helemaal niets van bestanden die alleen-online zijn. Daarom staan er slechts twee bestanden in de onderstaande map.

Zoals ik bovenaan opmerkte, moet je ervan uitgaan dat alles in een cloud-opslagdienst aanvankelijk alleen-online is en dat er dus geen afzonderlijke back-up van wordt gemaakt. Dat hoeft geen probleem voor je te zijn, de gegevens bevinden zich tenslotte allemaal in de cloud. Echter, als je mappen deelt met andere mensen is het mogelijk dat zij per ongeluk (of moedwillig) bestanden of hele mappen verwijderen, waardoor ze voor iedereen in de gedeelde groep worden verwijderd. In theorie zouden ze beschikbaar moeten zijn in een online prullenbak of verzameling verwijderde bestanden, maar daar wil je misschien niet op gokken. Een lokale back-up gemaakt met Time Machine, Backblaze, Super Duper of een andere app kan je tegen dergelijke fouten beschermen.

Zulke dingen gebeuren. Tonya kwam onlangs een situatie tegen waarin iemand in haar werkgroep per ongeluk een belangrijke Box-map met weken werk had verwijderd. Er waren misschien andere manieren om het te herstellen, maar het kopiëren van haar Time Machine-back-up ging snel en er was geen ticket bij de IT-ondersteuning voor nodig.

Daarom raad ik je aan om, als je voldoende schijfruimte hebt, alles van je cloudopslag te downloaden, in ieder geval tijdelijk. Breng alles naar je computer en laat Time Machine en je andere back-upsystemen een kopie maken. Als je vervolgens de schijfruimte wilt herstellen, stel je de mappen die je niet nodig hebt opnieuw in als alleen-online. Nieuwe bestanden die je maakt, zijn offline omdat je eraan werkt, dus ze komen automatisch in de back-ups terecht.

Tjongejonge! Toen ik aan dit artikel begon, dacht ik dat het een vrij korte uitleg zou worden van hoe de Dropbox-map was verplaatst na de migratie naar de nieuwe File Provider-extensie. Drie dagen van onderzoek en testen later, denk ik dat ik alle details begrijp. Maar misschien niet! Als je nog vragen hebt, stel ze dan in de reacties.