Mise à jour 19h15 : article complété
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.
Bien qu’alléchant au premier abord, il serait dommage de compromettre des années de travail en change de l’agrément de travailler en réseau.
Lr n’est aujourd’hui pas conçu pour ça, c’est clair.
On peut toutefois comprendre que certains soient prêts à prendre ce risque.
Dans ce cas, qu’ils le prennent pour eux-même et qu’ils ne fassent pas de prosélytisme sans mettre suffisamment en garde les utilisateurs potentiels contre les risques encourus.
« Dans ce cas, qu’ils le prennent pour eux-même et qu’ils ne fassent pas de prosélytisme sans mettre suffisamment en garde les utilisateurs potentiels contre les risques encourus. »
Oui, c’est bien ça le le fond du problème, et de la part de professionnels, c’est inquiétant.
Il me semble que dans tous ces échanges on été quelque peu mélangé les notions :
- D’utilisation en réseau
- D’utilisation concurrente d’un même catalogue (ce qui implique un réseau).
Il est évident que LR n’est pas aujourd’hui en mesure d’être utilisé de manière concurrente, du fait de SQLite et de l’implémentation LR associée, et qu’une telle utilisation est à proscrire.
Pour cette évolution attendue je ne pense pas que ceci induise un surcout significatif : il existe des moteurs de base de données open source qui répondent aux exigences, et l’adaptation du code de LR à un accès concurrentiel n’a rien de bien complexe pour un développeur aguerri. Après ça… les politiques tarifaires des éditeurs sont imprévisibles. Réponses avec la version 5 ?
Pierre,
Non, il n’y a pas de mélange entre l’accès concurrentiel et l’utilisation en réseau du catalogue, mais les deux sont forcément liés.
Les sites que j’évoque ont au moins eu l’honnêteté d’être très clairs quant aux accès concurrentiels, en soulignant qu’ils sont exclus.
Mais c’est également une bonne occasion d’en parler et de dire pourquoi Lightroom ne le permet pas, et ne le permettra pas, tout au moins avec l’architecture actuelle.
Je suis d’accord sur le fond de l’article de Gilles, et comme c’est un peu mon domaine je voudrais completer le commentaire de Pierre.
Il faut distinguer 2 niveaux d’utilisation :
1) l’utilisation multi-machines, par ex un ordi de bureau et un portable, par un seul utilisateur. Cela peut etre très utile en pratique, et beaucoup le demandent.
SQLite version 3.x possède les mécanismes de vérouillage internes qui permettraient de bloquer toute la base de données, comme maintenant (fichier .lock) mais sans faire appel à des mécanismes extérieurs de OSX ou de Windows. Ce vérouillage global est relativement simple à programmer, mais Adobe le fera-t-il ? That is the LR 5.X question.
2° l’utilisation multi-utilisateurs, ou il faut gérer les conflits d’accès à un niveau beaucoup plus fin, ce qui représente une programmation beaucoup plus délicate, surtout sur un programme non prévu à l’avance. SQLite 3.x possède les mécanismes nécessaires, mais je pense qu’Adobe ne le fera jamais avec LR, il s’agit d’une autre dimension d’utilisation, de prix, etc..
Essayons d’avancer sur un préalable mono-utilisateur ce sera déjà pas mal pour aider les malheureux lecteurs de cette nouvelle controverse qui est en train de brouiller les esprits.
Une question subsidiaire toutefois :
En admettant que l’on trouve son compte à laisser les aperçus dans le dossier (coût de l’abonnement et durées des transmissions)
L’option Dropbox est elle toujours proscrire elle aussi ?
Je dis bien en mono-utilisateur qui ne connecte qu’une machine à la fois.
Je pense que placer le catalogue sur DropBox est inutilement compliqué et hasardeux, sans compter qu’on est soumis aux aléas des connexions internet, et que les performances ne sont pas à la hauteur. L’article de Seb sur fotopassion.fr est parfaitement clair à ce sujet, contrairement aux gesticulations d’autres rédacteurs de sites que je ne nommerai pas ici.
À la maison ou en studio, je ne vois vraiment pas l’intérêt de pouvoir accéder à un catalogue de cette manière : on utilise un ordi principal, et on se sert du portable pour le travail occasionnel, facilement transférable dans le catalogue principal, avec toutes les garanties de fiabilité et de sécurité… alors, what else ?
Absent de France pendant plusieurs mois d’hiver, j’ai solutionné le problème en stockant photos, catalogue et backup sur un DD externe connecté en USB3.
J’emporte donc le portable et le DD plus un deuxième pour la sauvegarde complète de l’ensemble avec SyncBackFree.
Sur place m’attend l’écran qui va bien, et le tour est joué.
Bien sûr, on est là dans le cadre d’un utilisateur unique.
Une base de données (surtout les bases de données de type SQL) ont à gérer deux besoins contradictoires : être réactives, performantes d’un coté et garantir que les données sur disques sont dans un état cohérent, que rien ne sera perdu en cas de panne. Le premier demande de ne jamais accéder au disque, le seconde de toujours y accéder. Il existe de nombreux mécanismes subtils pour parvenir à réconcilier ces deux frères ennemis, mais il demande un nombre réduit d’intermédiaire entre l’application et les plateaux du disque. Les protocoles de partage de fichier sont trop complexes trop peu fiable pour ça : perte de paquets introduisant des délais importants, trop de couches de caches, pannes difficilement détectables. La moindre erreur peut détruire toute la base. Un accès unique d’une base de données sur un stockage réseau est déjà un exercice de haut vol, réservé à des environnements professionnels très couteux (Oracle, NetApp). Un accès partagé n’est envisageable que sur architecture de type client/serveur, pour lequel SQLite n’a jamais été conçu.
J’adore SQLite parce que justement, entre autre il ne peut pas être utilisé en réseau donc, il est plus facile de déployer une base de données SQLite que les autres, un simple glisser-déplacer est suffisant.
Dans les autres cas, il faut définir un serveur, un administrateur de base de données, une stratégie de sauvegarde etc… C’est plus compliqué…
Mais si le développement a été fait dans les règles de l’art, il est assez simple de changer de base de données. Ce sont des bases de données SQL, le language SQL est normé et très bien respecté par SQLite.
Ce que je veux dire est que le fait que LR utilise SQLite n’est pas un frein pour changer de base de donnée mais plutôt comment l’architecture du logiciel est articulé.
Il est évident si les appels à la bd ne sont pas encapsulés, le portage de LR vers une autre bd deviendra vite problématique.