Bonjour à tous,

Je reviens un instant sur les différentes polémiques, concernant les méthodes mises en avant par certains sites pour contourner l’interdiction de placer un catalogue Lightroom en réseau.

Adobe et, plus particulièrement, les développeurs de Lightroom déconseillent totalement d’utiliser un catalogue en réseau (que ce soit la simple installation qui va générer un message d’alerte, ou par l’intermédiaire d’images disques et de liens symboliques). De ce fait, j’ai donc été voir ce que raconte le site officiel SQLite, qui est le format de base de données employé par Lightroom. Et le moins qu’on puisse dire, c’est que la lecture, en dehors des passages techniques plutôt abscons, est forte en enseignements et surtout, sans aucune ambiguité à ce propos : la moindre faille qui se produit lors de l’écriture dans le catalogue peut entraîner une corruption de ce dernier, comme l’explique cette page :

« 6.0 How To Corrupt Your Database Files:

SQLite uses POSIX advisory locks to implement locking on Unix. On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem. »

Traduction :

« 6.0 Comment corrompre votre base de données :

SQLite utilise des verrous POSIX pour Unix. Sous Windows, il utilise les routines LockFile(), LockFileEx(), et UnlockFile(). Dans ce cas, SQLite suppose que ces routines de contrôle fonctionnent comme il se doit et, si ce n’est pas le cas, on se retrouve avec un risque de corruption de la base de données. POSIX est également connu pour ses propres problèmes techniques, sans parler de la possibilité qu’il ne soit pas utilisé sur les implémentations NFS (y compris les versions récentes de Mac OS X), et des problèmes de verrouillage de fichiers en réseau ont été signalés sous Windows. Dans ce cas, la meilleure protection est de ne pas utiliser de base de données SQLite en réseau. »

Ce n’est donc pas moi qui l’affirme mais bien le site du développeur SQLite sur cette page (section 6.0) !

Voici un autre extrait de ce qui figure sur cette page du site SQLite :

« If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it. »

Traduction :

« Si vous utilisez plusieurs programmes pour accéder à une base de données placée sur un réseau, tournez vous vers une solution client/serveur au lieu de SQLite. SQLite fonctionnera sur un réseau mais, en raison de la latence de ces systèmes, les performances seront dégradées. De plus, les routines de verrouillage de systèmes de fichiers en réseau ne sont pas complètement fiables (aussi bien sous Unix que Win). Dans ce cas, il sera possible à deux ou plusieurs programmes clients de modifier la même base de données au même moment avec, pour résultat, une corruption de la base de données. Si le cas se présente, et en raison des problèmes potentiels cités, SQLite ne pourra rien faire pour éviter la corruption. »

Le constat est parfaitement clair : SQLite présente un certain nombre d’avantages comme la compacité, la simplicité, la rapidité et la fiabilité, qui lui ont valu d’être retenu pour le système de catalogue de Lightroom. Néanmoins, il existe des situations à risque et c’est bien pour cela que je suis monté au créneau par rapport aux astuces publiées sur les sites mentionnés. Non pas parce que la recherche de solutions alternatives soit condamnable, bien au contraire, mais parce que les problèmes de sécurité et les risques inhérents à ce genre de manipulation ont été négligés ou traités par dessus la jambe. De plus, ces articles se contentent de décrire des procédures de mise en réseau du catalogue, mais ne s’aventurent pas dans l’utilisation concrète au quotidien. Pourquoi ? Tout simplement parce que ça ne présente aucun intérêt concret, que la manipulation est compliquée et hasardeuse pour l’utilisateur lambda (tout le monde n’est pas un crack en informatique, loin de là).

Bien sûr, beaucoup de photographes aimeraient une version à accès concurrentiel de Lightroom. Mais, pour cela, Adobe devra profondément modifier le logiciel, choisir un autre système de base de données, ce qui aura un impact conséquent sur le coût : je prends pour exemple Portfolio 11 Server, produit par Extensis, un vieux routier, et qui vient de sortir. La version monoposte coûte 260 US $, et la version Server en coûte 2400. Vous voyez qu’on ne joue plus dans la même cour, et Portfolio ne fait que de la gestion de fichiers numériques, tandis que Lightroom assure également le développement et la correction de fichiers Raw, et on ne parle pas des modules de sortie et créatifs ! En effet, comment gérer des aperçus, un catalogue et des métadonnées de développement en accès concurrentiel ? Vous voyez que le défi est assez difficile à relever.

Enfin, pour revenir au catalogue et à la base de données, je terminerai avec les conseils suivants, que j’ai déjà partiellement donnés dans mes articles précédents :

- Sauvegardez votre catalogue et vos photos au quotidien, sur deux volumes différents, notamment si votre production est intense.

- Ne tentez pas de placer votre catalogue en réseau en utilisant une des astuces publiées ailleurs : le jeu n’en vaut tout simplement pas la chandelle.

- Si vous avez la curiosité d’aller dans le dossier de votre catalogue lorsque celui-ci est en service (Paramètres du catalogue > Afficher), vous verrez deux fichiers nommés nomdevotrecatalogue.lrcat-journal et nomdevotrecatalogue.lrcat.lock (voir capture ci-dessus). Le premier sert de tampon pour l’écriture des données, le second empêche les écritures intempestives dans le catalogue. Évitez de les supprimer.

Ceci est mon point de vue de simple utilisateur de Lightroom, je ne suis ni informaticien, ni spécialiste des bases de données, je ne prétends pas être ce que je ne suis pas, mais je connais parfaitement le logiciel que j’utilise, et je suis particulièrement convaincu de la nécessité de protéger ses propres biens numériques … et je n’ai pas co-traduit, avec Volker Gilbert, le DAM Book  de Peter Krogh pour rien, sans le lire et sans en tirer certaines leçons !

À bientôt,

Gilles.