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.

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.

 

 

Het bloed kruipt … net als water

Ben ik toch gaan uitzoeken hoe CSS werkt. Het standaard thema stond me niet aan. Ik zie het als knutselen. Alleen heb je aan het eind geen garagezeep nodig om je handen schoon te maken.

Heb al wel een nuttig doel voor de site gevonden. Snel delen van foto’s met familie en vrienden. Niet de full-size versie van de plaatjes.  Maar plaatjes die erop het computerscherm leuk uitzien. Dat is in eerste instantie voldoende. (1000 langste zijde, 72dpi, kwaliteit 60 voor jpegs vanuit de lichtkamer). Dan kun je later nog altijd de full-size, of raw meenemen als mensen die willen hebben.

En over de titel. Is bloed polair? Water is polair. We zijn voor 70% water. Bloed is waterachtig. Het lijkt erop dat water kruipt. Omdat het polair is? Bloed kruipt. Omdat het polair is?