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 1 – de aanleiding

De uitgangssituatie. Je werkt sinds 1978 met computers. Dus je hebt tijd genoeg gehad om een archief aan digitale data op te bouwen. Met name de laatste jaren is je digitale archief aan het groeien. Meer precies de hoeveelheid digitale data die je zelf produceert is toegenomen. Denk aan foto’s.

Dat alles staat op een NAS-je. Netjes in RAID-5. Daarnaast heb je een stapel harde schijven met de back-up van de gegevens. Deze schijven liggen in hetzelfde huis als waar je NAS staat. Wat dat betreft is de situatie dezelfde als van een papieren fotoboek. Huis weg, fotoboek weg.

Kan dat ondertussen, we zitten in 2012, niet online? Ja dat kan. Na wat browsen kies ik een Nederlandse provider. Iedereen die hetzelfde pad opgaat wil ik adviseren. Laat je niet verleiden door een mooie website. Kijk naar reviews. Er zit heel wat kaf tussen. Goed ik kies voor een Nederlandse provider met servers in Nederland. Schijfruimte toegankelijk via WebDav. Dat is wat je afneemt. Verder geen fratsen. Wil ik ook niet. Alleen online dataopslag.

Contract afgesloten. Username en wachtwoord ontvangen. Aan de slag.