Dataopslag deel 5 – we leren

Ok. De directories zijn opgepoetst. Finder niet gebruiken. Maar vroeger of later ga je toch met Finder naar een directory op een netwerkshare. En dan? Beginnen we van voren af aan? Wel de oplossing staat hier:

http://noahlittle.wordpress.com/2008/08/10/mac-clutter-on-windows-getting-rid-of-ds_store-and-resource-fork-files/
Het commando is.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Voer uit in FInder en de bestanden meoten niet meer verschijnen. Moet je wel voor elke gebruiker doen. Hmm kan dat niet in een system-wide profile. Onder motorkap is het toch wel *nix-like.

 

Dataopslag deel 4 – nu gaan we lopen

Goed. Voorgekookte oplossingen voor mijn probleem bestaan niet. Eerst maar eens uitzoeken wat nu het probleem is. Te beginnen bij Finder.

Finder kopieert de .DS_Store bestanden mee en maakt ._<filenaam> bestanden aan voor de resourcefork van de databestanden. Het bestandssysteem van de Mac HFS+ wijkt af van andere (die ik ken :-)) door het gebruik van een datafork en resourefork voor de opslag van een bestand. De datafork is het eigenlijke bestand, de resourcefork bevat informatie over het bestand en zaken als bijvoorbeeld een icoon.

Maar gebruikt OSX de resourcefork nog wel en waarvoor dan? Na wat zoeken op www twee commando’s gevonden om de resourcefork te manipuleren. DeRez en Rez. Nu een test. Ik gebruik Yep om bestanden te taggen. Komt die tag bij het bestand in de resourcefork of niet. Nee dus. Bestand blijft even groot in finder en via ls -al in een terminal window.

Dan nog een leuke. Volgens

mdutil -s /Volumes/webdavvolume

is  Indexing disabled.

Maar bij een unmount in Finder van het webdavvolume krijg ik de melding dat dat niet kan omdat Spotlight het volume in gebruik heeft. Huh???

Komt dat nu door de gekopieerde .DS_Store bestanden of wat?

Tijd om het geheugen op te frissen. Ik wil alle .DS_Store en ._<filenaam> bestanden weg hebben op het webdavvolume. Daar had je iets van eval of xargs voor. Na een zoek op www kan ik de commando’s samenstellen.

find . -iname “._*” -type f -print0 | xargs -0 /bin/rm

gevolgd door

find . -iname “.DS_Store” -type f -print0 | xargs -0 /bin/rm

Dat poetst alles weg.  De aanname is dat de resourcefork obsolete is. Als deze nog wordt gebruikt dan waarschijnlijk door programma’s en pakketten zoals OSX ze bedoeld. Niet in databestanden. Bovendien is de bron van een hoop databestanden niet de Mac, maar bijvoorbeeld de fotocamera. Dus ik verwacht geen grote problemen.

En anders… kan ik alsnog opnieuw gaan kopiëren. Hoewel ik dan beter dmg’s of zips kan maken denk ik.

 

 

Dataopslag deel 3 – de eerste stapjes

Finder is een crime. Om de haverklap een zie je een draaiend wiel. Ook als je op een lokale directory klikt. Een schijfherstel, permissies, biedt geen soelaas.

Kopieeracties via Finder lukken niet. Dan maar op zoek naar synchronisatiesoftware. Die is er genoeg. De volgende passeren de revue.

  • Synkron
  • Chronosync
  • Goodsync
  • Bonkey
  • DirSyncPro (geen reactie op e-mail)
  • Duplicati

Helaas falen ze allemaal. De test die ik uitvoer is vrij simpel. Synchroniseer een directory. Als de applicatie klaar is synchroniseer je de directory weer. En wat blijkt? Alle applicaties gaan weer vrolijk aan de slag terwijl er niets valt te synchroniseren.

Hoe komt dat? Wel ze kijken alleen maar naar datum tijdstempel en filegrootte. Met uitzondering van Goodsync. Die heeft een optie om MD5 checksums te berekenen. Maar een directory die al met Finder is gekopieerd gaat ook Goodsync helemaal opnieuw kopieren. Dat is niet de bedoeling want er staat ondertussen toch een gig of 100 online en om dat nu met 64kb per seconde weer opnieuw te gaan kopiëren ligt niet in de bedoeling.

Conclusie: de sync-software zal best werken voor gelijksoortige filesystemen. Maar in dit geval voor mij zijn ze niet bruikbaar. De functionaliteit die ik verwacht is er niet. Wat verwacht ik dan?

Vergelijking van bestanden op basis van bijvoorbeeld SHA1. Een geheugen. Zodat software niet elke keer dezelfde bestanden gaat kopieren of de checksum gaat berekenen aan de spiegelkant als het bestand niet is gewijzigd.

Heb even aan git gedacht. Git heeft alleen één nadeel. Het is een versiecontrole systeem. Alle bestanden staan in een lokale repository. Dan wordt mijn fotodirectory 310 Gigabyte in plaats van 155 Gigabyte.

 

 

Dataopslag deel 2 – kruipen

De online opslag is gebruiksklaar. Vanuit mijn mac is dat simpel te mounten via https. De volgende stap. In Finder pak je een directory, die met 155 gigabyte aan foto’s, en via een sleep actie gaat dat naar de online opslag.

Simpel. Nou nee. Het gaat een tijdje goed dan blijft Finder hangen. Bij het kopieren van een bestand wordt wel het bestand aangemaakt. Maar de grootte blijft nul bytes. Een beetje wat je krijgt na een touch.

Vervelend is ook dat zelfs als Finder wel doorloopt niet noodzakelijkerwijs alle bestanden zijn gekopieerd. Tot slot het is heel traaaaaaaaaaaaaaaaaaaaaag.

Dat laatste ligt aan de provider. Die vindt het blijkbaar niet leuk dat je upload. Dat is Tele2. Nu ja, dan exit Tele2 en laten we Ziggo eens proberen. Zelfde resultaat. De leverancier van de online storage biedt geen optie om een schijf in te lezen. Een deal met de internetproviders lijkt er ook niet in te zitten.

Ben nu een paar maanden aan het prutsen. Stoppen we ermee? Nee laten we eens kijken wat er aan de hand is. Er zijn twee problemen. De trage uploadsnelheid en de werking van Finder. De eerste is voorlopig een gegeven. Aan het tweede probleem valt wat te doen. Door al dat gepruts heb ik ondertussen een aardig inzicht in wat er allemaal gebeurd.