Normalment faig còpia dels meus documents en un clauer USB, formatat amb sistema de fitxers FAT32 (el format normal de Windows) per tal que sigui fàcil d'usar en qualsevol ordinador amb Windows, Linux o Mac OS X.
Aquesta còpia, l'actualitzo mitjançant rsync (el programa estàndard de sincronització de directoris en sistemes Unix) de manera que només es copien els fitxers modificats. Darrerament, però, m'havia adonat que també es copiaven cada vegada alguns -molts- fitxers vells, no modificats des de feia temps. Aparentment, la data de modificació era correcta, coincidia en l'original i en la còpia. Per què, doncs, es tornaven a copiar aquests fitxers?
Una inspecció més acurada em va donar la pista: en tots aquests fitxers problemàtics, la data de la còpia era un segon anterior a la data de l'original. Per exemple, si la data d'un fitxer del meu disc dur és "17 de setembre de 2007 17:41:53", la data de la còpia d'aquest fitxer al clauer era "17 de setembre de 2007 17:41:52". És a dir, la còpia era un segon anterior i per tant rsync entenia que era més vella que l'original. Llavors copiava el fitxer, però misteriosament es tornava a desar amb una data un segon anterior a l'original. Un cercle viciós. Sorprenent i intrigant.
L'explicació del misteri, en Google i en la documentació del FAT32. Resulta que en aquest sistema de fitxers, Microsoft utilitza 16 bits per registrar l'hora de modificació, però dividits d'una manera sui generis: 5 bits per a l'hora, 6 bits per als minuts... i només queden 5 bits per als segons, és a dir, 32 valors possibles, de 0 a 31, insuficients per als 60 segons que té un minut :-( La solució de Microsoft consisteix a dividir els segons reals per dos i agafar la part entera: int (53/2) = 26. Després cal multiplicar per dos aquest valor a fi d'obtenir -aproximadament- els segons originals: 26*2 = 52. Heus ací el segon que faltava!
El meu contraatac ha consistit a utilitzar psync en lloc de rsync. Psync és escrit en perl i per tant més fàcil d'adaptar. Tocant només una línia, he aconseguit que no es tinguin en compte les diferències de menys de dos segons en les dates dels fitxers i tot ha tornat a ser normal en les meves còpies :-)
(En altres sistemes de fitxers, i en general en el món Unix, açò no pot passar. En Unix les dates es computen com a nombre de segons transcorreguts des d'un moment històric definit arbitràriament: l'1 de gener de 1970. Si els inventors de l'Unix haguessin estat devots hermeneutes, podrien haver agafat el 23 d'octubre del 4004 abans de Crist, que és quan es va produir la creació del món segons aquell bisbe irlandès.)
Actualització febrer de 2009.- En versions posteriors del rsync inclòs amb el Mac (potser a partir del Leopard?) aquest problema de sincronització amb sistemes de fitxers FAT32 es pot resoldre molt fàcilment mitjançant l'ús del paràmetre --modify-window, que permet definir un interval de temps en segons dins del qual dues dates de modificació seran considerades idèntiques. Amb --modify-window=1 (que vol dir que una diferència d'un segon no compta) ja ho tenim arreglat :-)
--modify-window
When comparing two timestamps rsync treats the timestamps as being equal if they are within the value of modify_window. This is normally zero, but you may find it useful to set this to a larger value in some situations. In particular, when transferring to Windows FAT filesystems which cannot represent times with a 1 second resolution --modify-window=1 is useful.
Des d'aquest estiu està disponible una versió Aqua de l'OpenOffice.org 2.3.0, el programari ofimàtic lliure per excel·lència. Però aneu alerta que és una versió alfa: en fase de desenvolupament i per tant encara inestable!
Això m'ha passat avui amb el 
Nova versió de 
Nova versió de